copyright ©2004 virtusa corporation | confidential requirement engineering virtusa training group...

Copyright ©2004 Virtusa Corporation | CONFIDENTIAL

Requirement EngineeringVirtusa Training Group 2004Trainer: Ojitha KumanayakaDuration : 1 hour

2Copyright ©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.


UML for OOAD

training scope


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.

Needs

Features

Software Requirements

Product

Problem

Pro

ble

m D

om

ain

So

lutio

n D

om

ain

Use Case


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.


Exercise

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.


Functional & Nonfunctional Requirements

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


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

Stakeholder

Use case Model

Developers

Use case Details


Example Cost of Good Sold (COGS)


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.


Use Case Driven Approach


Requirement Model relations to Other Models


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.


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.


Use Case driven generic process


Risk mitigation


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.


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 gatherrequirements. If we don't startcoding right now, we'll never meetour deadline."


Requirements from GIP


USA UK INDIA SRI LANKA

copyright ©2004 virtusa corporation | confidential requirement engineering virtusa training group...

Documents