REQUIREMENTS ENGINEERING & MANAGEMENT Introduction to REM

A theory is the more impressive the greater the simplicity of its premises is. Albert Einstein (1879 1955)

Agilen Chelumbrun @ 2013

Learning Outcomes
By the end of this lecture you will be able to:
Understand the need for Requirements Engineering & Management Distinguish between the different types of Requirements Describe the principal Requirements Engineering activities and their relationships Identify the challenges involved in Requirements Engineering and Management

The Need for Requirements Engineering & Management

The Need for Requirements Engineering & Management

The first stage of requirements engineering is all about discovering the purpose for carrying out a project at all. The next is about defining any design constraints and documenting everything clearly. Identifying stakeholders and their needs, and documenting all of this in a form which is easy to understand and communicate is no mean feat.

The Need for Requirements Engineering & Management

However, this investment up front before any of the so called real engineering begins is incredibly important. Understanding what your stakeholders say they want, as well as what they really want, gives you a fighting chance later on in the project to make the right decisions and to deliver a solution that fits. With any engineering design project, its not enough to build the thing right. You need to build the right thing.

The need for Requirements Engineering & Management

European Software Process Improvement Training Initiative (1996) The principal problem areas in software development and production are the requirements specification and the management of customer requirements
In a study of errors in embedded systems, it was found that: ... difficulties with requirements are the key root-cause of the safety-related software errors that have persisted until integration and system testing

The need for Requirements Engineering & Management

The success of a project lies in the degree to which its purpose has been achieved. Requirements keep on changing throughout the development of the project and therefore needs to be managed. Critical determinants for software quality Errors in requirements are numerous and most expensive to correct.

What is a Requirement?
Definition of Requirement by IEEE
A condition or capability needed by a user to solve a problem or achieve an objective A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents

What is Requirements Engineering?

The field of Requirements Engineering (RE) is relatively new, so it seems appropriate to begin by asking some very basic questions: What is RE all about? When is it needed? What kinds of activities are involved in doing RE? We will begin with the idea of a software-intensive system, by which we mean an interrelated set of human activities, supported by computer technology. The requirements express the purpose of such a system. They allow us to say something meaningful about how good a particular system is, by exposing how well it suits its purpose. Or, more usefully, they allow us to predict how well it will suit its purpose, if we design it in a particular way. The idea of human-centered design is crucial the real goal of an engineering process is to improve human activities in some way, rather than to build some technological artefact. extract from 2004 Steve Easterbrook

What is a Requirement?
A requirement is a necessary attribute in a system, a statement that defines the capability, characteristic, or quality factor of a system in order for it to have value and utility to a customer or user. -By Ralph Rowland Young A requirement is a collection of needs arising from the user and various other stakeholders (general organization, community, government bodies and industry standards), all of which must be met By AybkeAurum & ClaesWohlin(Eds.)7

Types of Requirements
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 services and constraints. Written as a contract between client and contractor

Software design specification

A detailed software description which can serve as a basis for a design and implementation. This design specification is written for developers. And is usually a detailed version of the system requirements.

Requirements Classification
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.

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

Domain requirements
Requirements that come from the application domain of the system and that reflect characteristics of that domain

Examples of Requirements Specifications

Requirement Definition 1. The software must provide a means of representing and accessing external files created by other tools.
Requirement Specification 1.1 The user should be provided with facilities to define the type of external files. 1.2 Each external file type may have an associated tool which may be applied to the file. 1.3 Each external file type may be represented as a specific icon on the users display.

Requirement Readers
User requirements Client managers System end-users Client engineers Contractor managers System architects

System requirements

System end-users Client engineers System architects Software developers

Software design specification

Client engineers System architects Software developers

Levels of Requirements
Strategic Management Requirements at organisational level Tactical Management Operational Management
Tradeoff between technology-push and market-pull Business strategy Planned benefits of Competitiveness the product Technology Marketing Economic value of the product Packing requirements for a specific release Product architectures Resource management Implementation of a specific release

Requirements at product level

Change management Requirements volatility i.e. whether a particular requirement is subject to a syntactic or semantic change Validation in terms of which requirements will go to the next release.

Requirements at project level

Project planning Feasibility study Recruiting people

Project management Quality control

Types of Requirements
Functional Requirements - a description of the facility or feature required. Functional requirements deal with what the system should do or provide for users. They include description of the required functions, outlines of associated reports or online queries, and details of data to be held in the system.
Examples The user shall be able to search either all of the initial set of databases or select a subset from it The system shall provide appropriate viewers for the user to read documents in the document store Every order shall be allocated a unique identifier (ORDER ID) which the user shall be able to copy to the account's permanent storage area.

Types of Requirements
Non-Functional Requirements - a description and, where possible, target values of associated non-functional requirements.
Non-functional requirements detail constraints, targets or control mechanisms for the new system. They describe how, how well or to what standard a function should be provided. For example, levels of required service such as response times; security and access requirements; technical constraints; required interfacing with users' and other systems; and project constraints such as implementation on the organisation's hardware/software platform.

Types of Requirements
Non functional requirements also includes: Product requirements Requirements which specify that the delivered product must behave in a particular way, e.g. execution speed, reliability etc. Organisational requirements Requirements which are a consequence of organisational policies and procedures, e.g. process standards used, implementation requirements etc External requirements Requirements which arise from factors which are external to the system and its development process, e.g. interoperability requirements, legislative requirements etc.

Types of Requirements

Types of Requirements
Domain requirements

Describe system characteristics and features that reflect the domain

May be new functional requirements, constraints on existing requirements or may define specific computations If domain requirements are not satisfied, the system may be unworkable

Example: Train protection system Is to Compute the deceleration time

Types of Requirements
Domain requirements
Example : Library system Because of copyright restrictions, some received on-line documents must be deleted immediately after printing

Types of Requirements
User requirements
Should describe functional and non-functional requirements so that they are understandable by system users who don't have detailed technical knowledge User requirements are defined using natural language, tables and diagrams.

Requirements problems
The requirements do not reflect the real needs of the customer for the system. Requirements are inconsistent and/or incomplete. It is expensive to make changes to requirements after they have been agreed. There are misunderstandings between customers, those developing the system requirements and software engineers developing or maintaining the system.

Software Requirements Specification Documents

The requirements document describes:
Information about the application domain of the system e.g. how to carry out particular types of computation Constraints on the processes used to develop the system Description of the hardware on which the system is to run

In addition, the requirements document should always include an introductory chapter which provides an overview of the system, business needs supported by the system and a glossary which explains the terminology used. Should include both a definition and a specification of requirements

Users of an SRS document

System customers
Specify the requirements and read them to check that they meet their needs. They specify changes to the requirements. Use the requirements document to plan a bid for the system and to plan the system development process.

Managers

System engineers

Use the requirements to understand what system is to be developed

System test engineers

Use the requirements to develop validation tests for the system Use the requirements to help understand the system and the relationship between its parts.

System maintenance engineers

Requirements Engineering
Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour and to their evolution over time and across software families.

Why is RE difficult?
Businesses operate in a rapidly changing environment so their requirements for system support are constantly changing. Multiple stakeholders with different goals and priorities are involved in the requirements engineering process. System stakeholders do not have clear ideas about the system support that they need. Requirements are often influenced by political and organisational factors that stakeholders will not admit to publicly.

Why is RE difficult?
A perfect example of requirements engineering not being done well was the Mars Climate Orbiter mishap in 1999. The Orbiter, which cost $125 million, was lost because one software team was working in imperial units and another in metric units.
Now, this mistake should have been picked up and corrected during the integration and testing phases of the project, but a detailed requirements specification for the problematic software module might have been enough to prevent the mistake in the first place

Why is RE difficult?

Requirement Engineering Process

Refers to all life-cycle activities related to requirements

Stakeholders Perspective

Exercise
Suggest who might be the stakeholders in bank? Explain why it is almost inevitable that the requirements of different stakeholders will conflict in some ways?

Requirements Management
It is the process of understanding and controlling changes to system requirements
Different users have different requirements and priorities. It is often discovered that priorities given to different users needs to be changed. System customers impose requirements because of organisational and budgetary constraints. These may conflict with end-user requirements. The business and technical environment of the system changes and these must be reflected in the system itself.
New hardware may be introduced Business priorities may change with consequent changes in the system support which is needed New legislation and regulations may be introduced which must be implemented by the system

Practices involved in Requirements management

Requirements Elicitation, Specification and Modelling. Prioritization Requirements Dependencies and Impact Analysis Requirements Negotiation Quality Assurance

Challenges involved in Requirement Engineering & Management

E-commerce and Globalisation Accelerated System Development Off-The-Shelf-Systems Quality Assurance

Requirements Engineering in action

The Air Force wishes to engage a contractor to develop a control system for a new type of experimental aircraft. It conducts a requirements analysis, and draws up a detailed requirements specification. This specification is used as the basis of an invitation to tender.
Potential contractors bid on the contract. The Air Force chooses a contractor, AlphaCo, on the basis that the price that AlphaCo bid was within the Air Forces expected budget, and the Air Force was impressed with AlphaCos presentation, experience, and the expertise of its staff. A fixed price is agreed and the contract is signed. AlphaCo then implements the system according to the detailed specification, which also acts as a legal contract. The specification is regarded as fixed, although occasionally AlphaCo seeks to negotiate a change, usually when some part of the specification turns out to be infeasible to implement.

extract from 2004 Steve Easterbrook

Requirements Engineering in action

Happy Ending: AlphaCo delivers the control system several weeks early; it is tested by the Air Force, used for several years in experimental aircraft, and eventually adopted as the basis for an entire fleet of fighter jets. AlphaCo makes a small loss on the contract (it cost more to develop than the agreed price), but makes a large profit on subsequent contracts with the Air Force over many years.

extract from 2004 Steve Easterbrook

Requirements Engineering in action

Or perhaps: The specification turns out to be poorly written, and AlphaCos engineers cannot understand it. They build what they think is requested and write test cases using the same assumptions. The software passes the tests, but all the early test flights crash, and in one incident, a pilot is killed. The Air Force cancels the project, and considers not paying AlphaCo, but is advised by its lawyers that it cannot legally abrogate the contract, because the specification appears to have been met. AlphaCo makes a profit anyway as their development costs were significantly lower than the agreed price.
extract from 2004 Steve Easterbrook

Exercise
Identify the stakeholders of an ATM system
Write down 10 functional and 10 non-functional requirements for the ATM system

Exercise
Functional & Non-functional Requirements
Functional Requirements: Actions that a system must be able to perform without taking physical constraints into considerations. Non-functional Requirements: Describe the required attribute of the system (performance, security, etc.).

With Use Case

Use cases place the functional requirements into the context of a user. Use case can also be used to capture any non-functional requirements that are specific to the use cases.

Exercise
answer

Requirement Engineering in a few words

Requirements engineering is a key component of system development processes. If we pay attention to requirements, we reduce later problems in system development and operation. Requirements engineering will always be difficult because the requirements are reflections of a rapidly changing business environment. Traditional requirements engineering processes will have to evolve for new types of software system and business needs.

Requirement Engineering in a few words

Requirements engineering is a systematic method concerned with obtaining a formal specification of what a customer wishes an application to do. There are two major tasks in requirements engineering: 1. analysis 2. modelling Analysis is the process of determining what the customer wishes the system to do and formally creating a list of requirements that the customer can understand and agree to. Modelling is a process of interpreting the customer requirements into something that software engineers can understand.

Requirement Engineering in a few words

There are two major types of requirements: functional requirements and non-functional requirements. Functional requirements describe a specific function or task that the system should perform. They can describe services, reactions, and behaviours of the system.
Non-functional requirements are not concerned with the functionality of the system, but instead place constraints on the entire system.

Requirement Engineering in a few words

The six main types of non-functional requirements are: 1. security 2. privacy 3. usability 4. reliability 5. availability 6. performance.
Constraints are specific non-functional requirements that restrict the development of the system. Some constraints may be the operating system, implementation language, or hardware configuration.

Requirement Engineering in a few words

A major aspect of requirements engineering is the elicitation of requirements from the customer.
There are several ways to gather requirements throughout the development process, which include: 1. interviews 2. observations 3. examining documents and artefacts 4. Joint Application Development sessions 5. groupware, 6. questionnaires

Requirement Engineering in a few words

7. prototypes 8. customer focus groups 9. and the presence of an on-site customer.
Changes to requirements should be anticipated during the development process..

References
Distributed Multimedia Research Group, Department of Computing, Lancaster University Architectural Requirements in the Visual Architecting Process by Ruth Malan and Dana Bredemeyer, Bredemeyer Consulting Ian Sommerville 2004 , 7th Edition Software Engineering The Requirements Engineering Handbook by Ralph R. Young Engineering and Managing Software Requirements, Aybke Aurum Claes Wohlin