requirements engineering process

Requirement Engineering Process

 The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management

 Feasibility Studies

 A feasibility study decides whether or not the proposed system is worthwhile

 A short focused study that checks

• If the system contributes to organisational objectives

• If the system can be engineered using current technology and within budget

• If the system can be integrated with other systems that are used

 Based on information assessment (what is required), information collection and report writing

 Questions for people in the organisation

• What if the system wasn‘t implemented?

• What are current process problems?

• How will the proposed system help?

What will be the integration problems?

• Is new technology needed? What skills?

• What facilities must be supported by the proposed system?

Elicitation and analysis

 Sometimes called requirements elicitation or requirements discovery

 Involves technical staff working with customers to find out about

• the application domain

• the services that the system should provide

• the system‘s operational constraints

 May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc.

• These are called stakeholders

Problems of requirements analysis

 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

System models

 Different models may be produced during the requirements analysis activity

 Requirements analysis may involve three structuring activities which result in these different models

• Partitioning – Identifies the structural (part-of) relationships between entities

• Abstraction – Identifies generalities among entities

• Projection – Identifies different ways of looking at a problem

Scenarios

 Scenarios are descriptions of how a system is used in practice

 They are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a system

 Scenarios are particularly useful for adding detail to an outline requirements description

Ethnography

 A social scientists spends a considerable time observing and analysing how people actually work

 People do not have to explain or articulate their work

 Social and organisational factors of importance may be observed

 Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models

Requirements validation

 Concerned with demonstrating that the requirements define the system that the customer really wants

 Requirements error costs are high so validation is very important

• Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error

 Requirements checking

• Validity

• Consistency

• Completeness

• Realism

• Verifiability

Requirements validation techniques

 Reviews

• Systematic manual analysis of the requirements

 Prototyping

• Using an executable model of the system to check requirements.

 Test-case generation

• Developing tests for requirements to check testability

 Automated consistency analysis

• Checking the consistency of a structured requirements description

Requirements management

 Requirements management is the process of managing changing requirements during the requirements engineering process and system development

 Requirements are inevitably incomplete and inconsistent

• New requirements emerge during the process as business needs change and a better understanding of the system is developed

• Different viewpoints have different requirements and these are often contradictory