CSC440 Chapter 4: Requirements Engineering (Software Engineering, Sommerville, 10th Edition)

Two types of requirements

User and system

User requirements

Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.

system requirements

A structured document setting out detailed descriptions of the system's functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

System Stakeholders

Any person or organization who is affected by the system in some way and so who has a legitimate interest

Types of stakeholders

- End users

- System managers

- System owners

- External stakeholders

Functional Requirements

- Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

- May state what the system should not do.

Non-Functional Requirements

-Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

-Often apply to the system as a whole rather than individual features or services.

Domain requirements

Constraints on the system from the domain of operation rather than the from the specific needs of the system users

Requirements imprecision

• Problems arise when requirements are not

precisely stated.

• Ambiguous requirements may be interpreted in

different ways by developers and users.

• Consider the term 'search'

- User intention - search for a patient name across all appointments in all clinics;

- Developer interpretation - search for a patient name in an individual clinic. User chooses clinic then search.

Types of non-functional requirements

1) Product: Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.

2) Organisational: Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.

3) External: Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc

Metrics for specifying non-functional requirements

- Speed

- Size

- Ease of use

- Reliability

- Robustness

- Portability

Requirements Engineering process activities

1) Requirements elicitation

2) Requirements analysis

3) Requirements validation

4) Requirements management

Requirements elicitation and analysis

-Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system's operational constraints.

Stages of Requirements Elicitation

1) Requirements discovery

2) Requirements classification and organization

3) Requirements prioritization and negotiation

4) Requirements specification

Difficulties of Requirements Elicitation

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

Two fundamental approaches to requirements elicitation

1) Interviewing

2) Observation or ethnography

Types of Interviews

1) Closed: interviews based on pre-determined list of questions

2) Open: where various issues are explored with stakeholders.

Problems with Interviews

- Application specialists may use language to describe their work that isn't easy for the requirements engineer to understand.

- Interviews are not good for understanding domain requirements

Keys to effective interviewing

- Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to stakeholders.

- Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system.

Ethnography

-A social scientist spends a considerable time observing and analyzing how people actually work.

-People do not have to explain or articulate their work.

-Social and organisational factors of importance may be observed.

Pitfall of Ethnography

Ethnography is effective for understanding existing processes but cannot identify new features that should be added to a system.

Stories and Scenarios

-Scenarios and user stories are real-life examples of how a system can be used.

-Stories and scenarios are a description of how a system may be used for a particular task.

-Because they are based on a practical situation, stakeholders can relate to them and can comment on their situation with respect to the story.

A scenario should include:

1) A description of the starting situation

2) A description of the normal flow of events

3) A description of what can go wrong

5) Information about other concurrent activities

6) A description of the state when the scenario finishes

Requirements specification

- The process of writing down the user and system requirements in a requirements document.

- User requirements have to be understandable by end-users and customers who do not have a technical background.

- System requirements are more detailed requirements and may include more technical information.

Ways of writing a system requirements specification

-Natural language

-Structured and natural language

- Design description languages

- Graphical notations

- Mathematical specifications

Natural Language Specification

- Requirements are written as natural language sentences supplemented by diagrams and tables.

- Used for writing requirements because it is expressive, intuitive and universal. This means that the requirements can be understood by users and customers.

Guidelines for writing requirements

1) Invent a standard format and use it for all requirements.

2) Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements.

3) Use text highlighting to identify key parts of the requirement.

4) Avoid the use of computer jargon.

5) Include an explanation (rationale) of why a

requirement is necessary.

Problems with natural language

1) Lack of clarity - Precision is difficult without making the document difficult to read.

2) Requirements Confusion - Functional and non-functional requirements tend to be mixed up

3) Requirements amalgamation - Several different requirements may be expressed together.

Structured language specifications

An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. (works well for say embedded systems but is too rigid for business system requirements)

Form-Based Specifications

• Definition of the function or entity.

• Description of inputs and where they come from.

• Description of outputs and where they go to.

• Information about the information needed for the computation and other entities used.

• Description of the action to be taken.

• Pre and post conditions (if appropriate).

• The side effects (if any) of the function.

Tabular Specification

- Used to supplement natural language.

- Particularly useful when you have to define a number of possible alternative courses of action.

- For example, the insulin pump systems bases its computations on the rate of change of blood sugar level and the tabular specification explains how to calculate the insulin requirement for different scenarios.

Use Cases

• Use-cases are a kind of scenario that are included in the UML.

• Use cases identify the actors in an interaction and which describe the interaction itself.

• A set of use cases should describe all possible interactions with the system.

• High-level graphical model supplemented by more detailed tabular description

• UML sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

The Software Requirements document

- Official statement of what is required of the system developers.

- Should include both a definition of user requirements and a specification of the system requirements.

- It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it.

T or F: Systems developed incrementally will, typically, have more detail in the requirements document.

FALSE, they will typically have less detail

Structure (sections) of a Requirements Document

- Preface

- Introduction

- Glossary

- User requirements definition

- System architecture

- System requirements specification

- System models

- System evolution

- Appendices

- Index

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 u to 100 times the cost of fixing an implementation error)

Requirements Checking Types

1) Validity - Does the system provide the functions which best support the customer's needs?

2) Consistency - Are there any requirements conflicts?

3) Completeness - Are all functions required by the customer included?

4) Realism - Can the requirements be implemented given available budget and technology?

5) Verifiability - Can the requirements be checked?

Techniques for Requirements Validation

1) Requirements reviews - Systematic manual analysis of the requirements

2) Prototyping - Using an executable model of the system to check requirements.

3) Test-case generation - Developing tests for requirements to check test-ability

Requirements Reviews

• Regular reviews should be held while the requirements definition is being formulated.

• Both client and contractor staff should be involved in reviews.

• Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage.

Review Checks

1) Verifiability - Is the requirement realistically testable?

2) Comprehensibility - Is the requirement properly understood?

3) Traceability - Is the origin of the requirement clearly stated?

4) Adaptability - Can the requirement be changed without a large impact on other requirements?

Changing requirements

- The business and technical environment of the system always changes after installation. (New hardware, new legislation, changing business priorities etc.)

- The people who pay for a system and the users of that system are rarely the same people.

- Large systems usually have a diverse user community, with many users having different requirements and priorities that may be conflicting or contradictory.

Requirements Management

The process of managing changing requirements during the requirements engineering process and system development.

Requirements management decisions

1) Requirements identification - Each requirement must be uniquely identified so that it can be cross-referenced with other requirements.

2) A change management process - This is the set of activities that assess the impact and cost of changes.

3) Traceability policies - These policies define the relationships between each requirement and between the requirements and the system design that should be recorded.

4) Tool support - Tools that may be used range from specialist requirements management systems to spreadsheets and simple database systems.

Three principle stages to a change management process

1) Problem analysis and change specification

2) Change analysis and costing

3) Change implementation