Chapter – 6Chapter – 6

REQUIREMENTS REQUIREMENTS CAPTURECAPTURE

From Vision to Requirements From Vision to Requirements

Requirements Capture - DifficultRequirements Capture - Difficult

A System has many Users.

Each of them know what to do but no one knows the

entire picture.

Users do not know the operation as a whole can be

more efficient.

Most users do not know what aspect of their work can

be converted in software.

Users do not know what the requirements are and how

to specify them in a precise manner.

Purpose of Requirements WorkflowPurpose of Requirements Workflow

Aim development towards the right system. Describing the systems requirement well enough

so that an agreement can be reached between the between the customer and the developer what the system should or should not do.

Customer must be able to read and understand the results of requirement capture.

Help the project manager plan the iterations and customer releases.

Overview of Requirements CaptureOverview of Requirements Capture Every software is unique. This singularity comes from the variations in the

kind of system, the customer, the development organization, the technology etc.

Where do we start :– Start by developing the business model.– Start with a business model already developed.– Start with the software already in place which may

serve as an input.– The customer may have developed the a detailed

requirement specification which is not based on object model

The Interbank Consortium, a hypothetical financial institution, is facing major changes due to deregulation, new competition and capabilities enabled by the World Wide Web. The Consortium plans to develop new applications to support the rapid changes in the financial market.It has directed its software development subsidiary, Interbank Software, to initiate development of there applications.Interbank Software decides to design the Billing and Payment System in collaboration with some of its main bank customers.The System will use the internet for sending orders, invoices and payments between buyers and sellers. The banks motivation for developing the system is to attract new customers by offering its customers a low payment processing fee. The bank will also reduce its wage costs by processing payment request through the internet instead of manually through cashiers.The motivation for buyers and sellers are to reduce costs, paperwork and processing time. For example they will not have to send orders or invoices by paper mail. The payment of invoices will be handled between the buyer’s computer and the seller’s computer. Buyers and sellers will also have a better overview of the status of their invoices and payments.

An exampleAn example

Requirements Capture - Example Requirements Capture - Example

Different starting point poses different kinds of risk. Hence

choose the strategy that poses the minimum risk.

Despite the differences in the starting points certain steps

are feasible in most cases which allows us to suggest an

archetypal workflow. These workflows are performed

together:

1.) List Candidate Requirements. 2.) Understand System

context. 3.) Capture functional requirements. 4) Capture no-

functional requirements

List Candidate Requirements.List Candidate Requirements.

During the life of a system people come up with many good ideas

which might turn into real requirements.

Save these ideas as potential requirements for some future release

of the product.

This feature list grows as more and more ideas are added to the list

and shrinks as these features become requirements and transformed

into usecases.

The feature list may contain the following information

a.) Short Name b.) Description c.) Status d.) Estimated Cost e.) Priority

f.) Associated level of risk associated in implementing the feature.

This planning values are used to estimate the size of the project.

Understand System ContextUnderstand System Context

To capture the right requirements and to build the right system one needs to have a firm grasp of the context.

2 approaches to express the context of a system in a form usable by Developers:– Domain Modeling : Describing the important concepts of the

Context as domain objects and linking these objects to one another. Identifying and naming these objects help us develop a glossary of terms which is used by the team. Later the domain objects help us identify some of the classes during analysis and design of our system.

– Business Modeling: Is a superset of Domain Modeling and it describes the business process supported by the system. Also specifies the competencies required in each process. It is a most systematic process for capturing requirements for business applications.

Capturing Functional RequirementsCapturing Functional Requirements

Identify system requirements is based on usecases which captures functional & nonfunctional requirements.

Specification of user interfaces associated with usecases.

Each usecase represent one way of using the system. Each user needs several different usecases, each representing the different ways he or she uses the system.Capturing the usecases that are actually wanted from the system such as those that support the business and that the user thinks allows them to work in a comfortable way, requires that we know the user and the customers need thoroughly. To do so we need to understand the system context, interview users, discuss proposals and so on.

Capture Non-Functional Reqs.Capture Non-Functional Reqs.

Non Functional requirements specify system properties like :– Environmental & implementation Constraints.– Performance– Platform dependencies - Maintainability– Extensibility - Reliability

Some nonfunctional reqs. refers to some real-world phenomena like accounts in a bank.

Some nonfunctional requirements are more generic and cannot be connected to a particular usecase or real world class (Supplementary reqs).

Summing UpSumming Up

WORK TO BE WORK TO BE DONEDONE

RESULTING RESULTING ARTIFACTSARTIFACTS

List Candidate Requirements

Feature List

Understand system context

Business or Domain Model

Capture Functional Requirements

Usecase Model

Capture Non-Functional Requirements

Supplement Requirements or Individual use cases.

Role of Requirements in S/W life cycleRole of Requirements in S/W life cycle

Role of Requirements in S/W life cycleRole of Requirements in S/W life cycle

Inception Phase– Identify most usecases & detail most critical ones (<10%)

Elaboration Phase– Capture most of the remaining requirements (80%) & describe

most of the usecases. Implement some architecture related usecases (5% to 10%).

Construction Phase– Capture remaining usecases.

Transition Phase– No requirement capture.

Domain ModelDomain Model

Captures the most important types of objects in the context of the system.Many of the objects can be found form the requirement specification or by interviewing Domain experts.3 Types of Domain Objects :– Business Objects :- Things that manipulate business like orders,

account, contract etc.– Real World Objects:- Objects or concepts that a system needs to

keep track of like missiles, aircraft – Events that will or have transpired :- like arrival and departure of

aircrafts or lunch break.

Objects are related to one another by association.

ExampleExample

The system will use internet to send orders, invoices and payments between the buyers and sellers.The system helps the buyer prepare order, the seller to evaluate orders and send invoices and the buyer to validate the invoices and effect payment from the buyers account to that of the seller.

An order is the request from a buyer to a seller for a number of items. Each item occupies a line in the order. An order has attributes like date of submission and delivery address.

An invoice is a request for payment sent from a seller to the buyer in response to an order for goods and services. A invoice may be a request fro payment for several orders.

An invoice is paid by transferring money from the buyer’s account to the sellers account.

ExampleExample

ORDER

Date of submission

Delivery Address

INVOICE

Amount

Date of submission

Last date of Payment

ACCOUNT

Balance

Owner

ITEM

Description

Picture

Cost

payable

buyer

seller1

1

1..*

1..*

Developing Domain ModelDeveloping Domain Model

Done by Domain Analyst using UML.Understand the important classes within the context of

the domain.In small business domains this may not be necessary.

Instead a glossary of terms may suffice.Helps Customers, developers use a common vocabulary

which is necessary to share knowledge with others.Domain modeling should contribute to the understanding

of the problem that the system is suppose to solve in relation to its context.

Uses of Domain ModelingUses of Domain Modeling

The Domain Classes and the glossary of terms are used when developing usecases and analysis model. They are used :-– When describing the usecases and when designing the

user interface.– To Suggest class internal to the developed system

during analysis.

Domain Model is a special case of a more complete business model.

Business ModelBusiness Model

Technique for understanding the business process of the organization.

It describes the business processes of a company in terms of business use cases and business actors corresponding to business processes and customers.

Presents the system from the Usage perspective and outlines how it provides value to its users.

Business Models are supported by Use-case Model and object model.

What is a Business ModelWhat is a Business Model

Describes the processes of a company in terms of business usecases and business actors corresponding to business processes and customers.

Like the usecase model of a system software the business usecase model presents a system from the usage perspective and outlines how it provides value to its users.

What is a Business Model – ContWhat is a Business Model – Cont

It is an interior model of the business. It describes how each business usecase is realized

by a set of workers who are using a set of business entities and work units.

Each realization of business usecase can be shown in interaction diagram and activity diagram.

Entity – represents something such as invoice, which workers access , inspect, manipulate, produce or use in a business usecase.

Work unit – Set of such entities that forms a recognizable whole to an end user.

ExampleExample

Payment Handler

BuyerSeller

Buyer Seller

Due invoice

ACCOUNT INVOICE

What is a Business Model – ContWhat is a Business Model – Cont

Business Units and work units are used to represent the same kind of concepts as domain classes such as order, invoice, item or account hence depicted as before.

There are other diagrams to depict the workers, their interaction and how they use the business entities and work units.

Each worker, business unit and work unit may participate in the realization of more than one business usecase.

How to develop Business ModelHow to develop Business Model

The business model is developed in 2 steps– Business Modelers should prepare a business usecase

model that identifies the actors to the business and business usecases that the actors use. This business usecase model provide better understanding of the value the business provides to its actors.

– Modelers should develop a business object model consisting of workers, business entities and work units that together realize the business usecases.Business rules and other regulations imposed on the business are associated with these different objects.The goal is to create workers, business entities and work units that realize the business usecases as effectively as possible.

Supplementary RequirementsSupplementary Requirements

Non-functional requirements that cannot be associated with any particular usecase.

May or may not impact any usecases. Examples are Performance, interfaces,

physical design requirements and architectural, design and implementation constraints.

Traditional requirement capture methods are used and are developed along with the usecase model.

Types of Supplementary ReqmtsTypes of Supplementary Reqmts

Interface requirementsPhysical requirementsDesign constraintsImplementation constraintsOther Requirements– Security– Availability– Ease of learning