1. Chapter – 6

2. Requirements 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.

3. Purpose 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.

4. Overview 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

5. 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 example

6. 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

7. 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.

8. Understand 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.

9. Capturing 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.

10. 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).

11. Summing Up 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.

12. Role of Requirements in S/W life cycle

13. 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.

14. Domain 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.

15. Example 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.

16. Example ORDER Date of submission Delivery Address INVOICE Amount Date of submission Last date of Payment ACCOUNT Balance Owner ITEM Description Picture Cost payable buyer seller 1 1 1..*

17. Developing 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.

18. Uses 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.

19. Business 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.

20. What 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.

21. What 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.

22. Example Payment Handler Buyer Seller Buyer Seller Due invoice ACCOUNT INVOICE

23. What 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.

24. How 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.

25. Supplementary 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.

26. Types of Supplementary Reqmts Interface requirements Physical requirements Design constraints Implementation constraints Other Requirements –Security –Availability –Ease of learning