Software Requirements and the Requirements Engineering Process Chapters

Software Requirements and the Requirements Engineering Process Chapters 5 and 6

References n n n n Software Engineering. Ian Sommerville. 6 th edition. Pearson. Code Complete. Steve Mc. Connell. (CC) The art of requirements triage. Alan M. Davis. Computer. IEEE. March 2003. Testing whether requirements are right. Robin F. Goldsmith, JD. Go Pro Management Inc. NYC Spin Meeting. December 2004. (RG) Software Requirements. Karl E. Wieger. Windows Press. Dr. Gotel’s research web page Dr. Barrett slides, NYU

Requirements elicitation and analysis n n Stakeholder: Person or group of persons who will be affected by the system (directly or indirectly) All stakeholders should be involved in requirements elicitation and analysis n n n Stakeholders don’t know what they really want Stakeholders express requirements in their own terms Different stakeholders may have conflicting requirements Organisational and political factors may influence the system requirements The requirements change during the analysis process. New stakeholders may emerge and the business environment change

Different techniques for requirements elicitation and analysis n Different techniques for elicitation: n n n n Brainstorming Stories Prototyping Questionnaires Interviewing Viewpoint Scenarios Use cases

Requirements analysis n Read the paper ‘The Art of Requirements Triage’, Alan Davis, IEEE computer, March 2003 n n Prioritization, estimation of the resources to satisfy the requirements, subset of requirements that optimizes the probability of the system’s success Mo. SCo. W Criteria for requirements triage: n n M – Must have – mandatory requirements that are fundamental to the system S – Should have – important requirements that could be omitted C – Could have – optional requirements W – Want to have – the requirements really can wait

Interviewing and questionnaires n n n Interviewing: synchronous elicitation technique Questionnaires: asynchronous elicitation technique Based on: n n n Ask questions and listening/reading the answers Be prepared to ask follow-up questions Ask for documents you need Log the answers (to support, complete or contradict what was said/written) Involve all the stakeholders

Viewpoints n Viewpoints permits us to classify stakeholders and other sources of requirements n n Multi-perspective analysis / diversity of source of information are important 3 categories of viewpoints n n n Interactor viewpoints: People or other systems that interact with the system Indirect viewpoints: Stakeholders who do not use the system directly but who influence the requirements in some ways Domain viewpoints: Domain characteristics and constraints

Viewpoints n More specific viewpoints: n n n Providers and receivers of system services Systems interfacing with the new system Regulations and standards applying to the system Sources of business and non-functional requirements Engineering viewpoints: developing, managing, maintaining the system Marketing viewpoints

The VORD method n n n This method implements a viewpoint-oriented approach for requirements elicitation VORD = Viewpoint Oriented Requirements Definition It is based on: n Viewpoint identification n n Viewpoint structuring n n Allocating services to viewpoints Viewpoint data/control Group the viewpoints into a hierarchy Viewpoint documentation n Discovering the viewpoints, services and constraints Refine the description of the viewpoints, services and constraints Use of a template Viewpoint system mapping n Transform the analysis to an object-oriented design

VORD template

Example: ATM Viewpoint identification

Example: ATM Viewpoint structuring: Allocating services to viewpoints

Example: ATM Viewpoint structuring: Viewpoint data/control

Example: ATM Viewpoint structuring: Viewpoint hierarchy

Example: ATM Viewpoint documentation

Scenarios n n n If it often easier for people to relate on real-life example rather than abstract statements Scenarios are descriptions – sequences of events of how the system is used in practice. Scenarios are composed of: n n n A description of the initial state of the system A description of the normal flow of events in the scenario A description of what can go wrong and how it is handled Information on other activities that might be going on concurrency A description of the final state of the system

Use cases n n n n Use cases are a scenario-based technique for describing requirements Use cases identify the users of the system (actors) Use cases identify the tasks (use cases) Use cases relate the users and the tasks Use cases are typically illustrated with UML as stick figures or similar diagrams A set of use cases should describe all possible interactions with the system Use cases are more effective in capturing functional requirements

Example: Flights reservation system

Use-cases relationships n Use cases have relationships n Inclusions: n n Extensions: n n A use case contain the behavior from another use case (unconditional) Can be seen as a factorization Introduced by the <<include>> keyword A use case conditionally interrupts the execution of another use case to augment its functionality An extension point may specify a precondition for the extending behavior Introduced by the <<extends>> keyword Inheritance

Flights reservation system

Requirements specification n Examples of templates (Available in the Blackboard): n n Microsoft template. Karl E. Wiegers. Software Requirements. Windows Press. Volere template n http: //www. volere. co. uk

Textual descriptions of a usecases n The textual description of a use case includes: n n n Use case ID Use case name Actors Description Pre-condition Post-condition Normal course Alternative course Exceptions Includes Priority See also template of Karl E. Wiegers, Microsoft

Requirements validation n Requirements must be checked for: n n Validity, comprehensibility, traceability (source, dependency between requirements) consistency, completeness, realism and verifiability Validation techniques: n Requirements reviews n n Test-case generation n Tests are developed for the requirements Prototyping Mini-definitions of the requirements n n Expert review, two independent reviews Formal/informal Involvement of the stakeholders necessary A team redefine the requirements and compare them with the list of produced requirements There are lots of validation techniques (more than 21). Dr. Goldsmith’s presentation.

Requirements management n n n Requirements management deals with the process of managing changes in the requirements during the requirements engineering process and system development Requirements traceability is concerned with the relationships between requirements (dependencies), their sources and the system design CASE tools are necessary for the requirements storage and management

Traceability matrix n U: Uses W: Weak relationshi p A traceability matrix permits us to see the relationships/dependencies between requirements