Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour

2 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Why important ? establish a clear understanding of the problem so that potential solutions can be effectively weighted Key business requirements must be defined, including the ROI justification for each proposed alternatives can the be measured to determine which best solves the stated problem Without this requirements analysis, a UML- based approach may only help to deliver the wrong application faster and cheaper.

3 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL UML for OOAD training scope

4 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL The requirement pyramid Needs: Things that the stakeholder believe that the system needs to do. Features: Informal statement of system capabilities. Features have no precise definition and/or consistent level of abstraction. Requirements: Individual statements of conditions and capabilities to which system must conformed. Note: The separation of the problem domain form the solution domain indicates that the subject of the requirements specification is the solution rather than the problem.

5 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Need, Feature, Requirement Need, Feature and Requirement Relationship among the three kinds is expressed using traceability. There is no hierarchical decomposition of needs into features into requirements. Instead, these concepts are largely orthogonal, expressing different views of the system for different audiences. Needs and features are mainly to establish the context for the application of the use-case modeling approach.

6 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Use Case Relationship With Use Case Features can be mapped to the use cases. The granularity of the features and the use cases are very different. There can be many features provided by a single use case, or a feature could be provided by more than one use cases. The use case model itself is a vehicle for organizing the software requirements in an easy to manage way.

7 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Functional & Nonfunctional Requirements Functional Requirements: Actions that a system must be able to perform without taking physical constraints in to considerations. Nonfunctional Requirements: Describe the attribute of the system required. With Use Case Use cases place the functional requirements into the context of a user. Use case can also be used to capture any nonfunctional requirements that are specific to the use cases. Misconceptions related to Use Cases Use cases are nothing else than capturing functional requirements. Nonfunctional requirements are captured apart from the use cases.

8 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Why need use case For human kind always expecting mental model to simply the complexity. Stakeholder Mental Model is obvious. Need simple mental model that consistently applied throughout the design for developers. Use cases explore, form, and refine the mental model of how the system will work. Use case should describe how the system is used and what it does for its Stakeholders Use case Model Use case Details

9 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Example Cost of Good Sold (COGS)

10 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Use Cases in Architecture (4+1) Use case driven, architecture centric iterative and incremental process Architecture is the set of significant decisions about The organization of system software Interfaces of the structural elements and their composition. Behavior as specified in collaborations Composition of behavioral and structural elements to subsystems The static and dynamic elements and their interfaces, their collaboration & composition The use case model of a system encompasses the use cases that describe the behavior of the system as seen by its end users and developers. Use case model doesn’t specify the organization of a software system.

11 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Use Case Driven Approach

12 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Model relations to Other Models

13 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Use Case Driven Process First of all, what is a use case ? A use case is a sequence of actions that the system performs for its actors. How to use use-case in the generic process Use to capture functional and non-functional requirements Use case drive the process since most activities such as analysis, design, test and deployment performed starting from the use case. Sometime project estimations done from use cases. Analysis Model The analysis model is a detailed specification of the requirements and work as first cut of at design model, although it is model of its own. Analysis model is different from the design model in that it is a conceptual model rather than a blueprint of the implementation. Represent conceptual realization of use case model and input to the design model.

14 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Use Case Driven Process… cont… Design Model Hierarchical model with relationships Use case realization is collaborative complete realization of use case model with help of analysis model The design model is also a blueprint of the implementation.

15 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Use Case driven generic process

16 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Risk mitigation

17 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL IEEE 830 Documentation standards for Requirements Specification Unambiguous -- Every statement has one interpretation. Terms are clear and well defined. Complete -- All significant requirements are included. No items have been left for future definition. Verifiable -- All features specified as part of the project have a corresponding test to determine whether they have been successfully delivered. Consistent -- Conflicting terminology, contradictory required actions, and impossible combinations are notably absent. Modifiable -- Redundancy is absent; index and contents are correct. Traceable -- Each referenced requirement is uniquely identified. Correct -- Every stated requirement represents something required of the system to be built. This may sound obvious, but it is surprisingly easy to include extraneous requirements, or requirements that really pertain to a separate system entirely.

18 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL No time for requirements… "We don't have time to figure out what we need to build and deliver. If we don't start coding now…“ Never experience proper requirement analysis and no idea of its advantages. Over value themselves. Not responsibility of stakeholder requirements or investment Lack of knowledge in software processes even in Software Engineering Generally not well in managing things Ready to accept failures "We don't have time to gather requirements. If we don't start coding right now, we'll never meet our deadline."

19 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirements from GIP

20 Copyright ©2004 Virtusa Corporation | CONFIDENTIAL USA UK INDIA SRI LANKA