Requirements Engineering

Csaba Veres

Outline

What is requirements engineering? Why is it important? How can you do it (properly)?

Plan Requirements engineering, P11

overview quality evaluation (validation)

Using objects for Systems Analysis, P10, P13 differences in problem analysis, requirements, and design different objects in different phases

Requirements engineering and COTS, P14 special methods

Use cases, P12 motivation for use cases in requirements engineering how to write good use cases

Today’s lecture

Reading from Kotonya/Sommerville: Requirements Engineering: Processes and Techniques

Processes Intro Requirements processes

Techniques well known techniques

Why are requirements important?

Many systems are delivered late and over budget. they often don’t do what users wanted often not used to full effectiveness

Proper requirements definition can ease the problems. Each stage of development can multiply the problem by 10 times discovering problems at requirements: cost 1 discovering after design: cost 10 discovering after implementation: cost 100 discovering after rollout to client: cost 1000

What are requirements? Requirements define what the system is required

to do, and the circumstances under which it must operate. e.g.1. The system shall maintain records of all library

materials including books, serials, newspapers and magazines, video and audio tapes, reports, collections of transparencies, computer disks and CD-ROMS.

2. The system shall allow the users to search for an item by title, author, or ISBN.

3. The system’s user interface shall be implemented using WWW browser.

4. The system shall support at least 20 transactions per second.

5. The system facilities which are available to public users shall be demonstrable in 10 minutes or less.

What sorts of requirements?

The previous list contained different types of requirement:1. Very general requirements that set out in broad

terms what the system should do

2. Functional requirements

3. Implementation requirements

4. Performance requirements to specify minimum acceptable performance

5. Usability requirements

A complex web of needs ...

Functional requirements Non functional requirements

security speed usability (?)

Organisational standards Other interacting systems

... can lead to many problems

Requirements don’t reflect real needs Requirements are inconsistent/incomplete

e.g. requirement 1) above ... CDs don’t have ISBN .. author?

Misunderstandings between customers, users, developers ...

Requirements engineering aims at concrete, repeatable methods for doing the job as well as possible

FAQs about requirements

What are requirements? In addition to what we already talked about,

requirements can relate to:i. user-level facility (e.g. ’word processor should have spell

checker’)ii. general system property (e.g. ’the system should never

make personal information available’)iii. specific constraint on the system (e.g. ’the sensor must

be polled 10 times a second’)iv. business rules (specific computations, formulas)v. constraint on development (e.g. the system must be

developed using Ada)

FAQ

Requirements can be about what the system has to do

functional, non-functional how it has to do it

domain experts

FAQ

What is requirements engineering? Discovering, documenting, and maintaining

requirements Systematic, repeatable techniques to make

sure requirements are complete consistent relevant

FAQ

How much does RE cost? Depends on the project Around 10% to 15% of total cost

FAQ

What happens when the requirements are wrong?

Late delivery and inflated cost End-users not satisfied with the system

modification, abandoning Unreliable High cost of maintenance and modification

FAQ

What is a requirements engineering process? Structured set of activities to derive, validate, and

maintain requirements document elicitation analysis negotiation validation

Ideally should include timelines, tools, responsibilities, etc.

FAQ

Is there an ideal RE process? Yes.

Only joking ... System, organizational culture, etc. The few existing standards relate to process

outputs, not processes themselves

FAQ

What is a requirements document? THE official statement of the system

requirements Describes a number of lower level entities

(functional specifications, etc.)

FAQ

What are stakeholders? Anyone who has a direct or indirect bearing

on the system requirements end users, managers, development and

maintenance engineers, customers who rely on the system, external bodies (e.g. tax department)

Make sure ALL stakeholders are consulted, or there will be trouble!

FAQ

How do requirements relate to design? Seperate activities?

specification vs. solution what vs. how

In reality, often there are overlaps system has to fit within existing environment (e.g. ’data has

to be read from ORACLE DB’) large systems decompose into subsystems which have

their own requirements re use of existing software re use of approved ’patterns’ or solutions

FAQ

What is requirements management? The process of managing changes to

requirements document Change control

collect, verify, and assess changes Change impact management

how does the change impact the whole system? economic feasability

Systems engineering

”Software requirements” involves properties of the system as a whole software hardware operational processes

Computer systems are either: user-configured

no explicit system requirements COTS?

custom made all stakeholders participate in requirements

Different types of system Information systems

process information typically database access standard hardware RE: primarily software requirements

Embedded systems software used as a controller special purpose hardware and OS RE: hardware and software

Command and control systems combined information and embedded special purpose systems to aide decision making e.g. air traffic control, railway traffic control, military RE: software, hardware, operational processes

Emergent properties

”non constuctive” aspects of information systems follwing subsystem integration reliability maintainability performance usability security

General systems engineering processes

Systemrequirementsengineering

Architecturaldesign

Requirementspartitioning

Softwarerequirementsengineering

Sub-systemdevelopment

Systemintegration

Systemvalidation

The requirements document A text based document containing

the services and functions the system should provide the constraints under which the system must operate overall properties (i.e. constraints on the system’s

emergent properties) definitions of other systems which the system must

integrate with information about the application domain of the system,

e.g. how to carry out particular types of computation constraints on the process used to develop the system

Standards

No single standard exists, but several large organizations have proposed them

DOD, IEEE One of the simplest is IEEE/ANSI 830-1993

(IEEE, 1993)

IEEE, 1993

1. Introduction1. Purpose of the requirements document2. Scope of the product3. Definitions, acronyms and abbreviations4. References5. Overview of the remainder of the document

2. General description1. Product perspective2. Product functions3. User characteristics4. General constraints5. Assumptions and dependencies

IEEE, 1993

3. Specific requirementsfunctional, non functional, and interface

requirements. Also external interfaces, performance requirements, logical database requirements, design constraints, system attributes, and quality characteristics

4. Appendices

5. Index

Users of the document System customers

Specify the requirements and read them to check that they meet their needs. They specify changes to the requirements.

Managers Use the requirements document to plan a bid for the system

development process. 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

System maintanence engineers Use the requirements to help understand the system and the

relationship between its parts

Writing requirements

Natural language is often used Some common problems

complex conditional statements are confusing terminology often not precise or inconsistent writers assume too much knowledge and leave

out essential detail

3 essentials for requirements documentation writers

1. Requirements are read more often than they are written

2. Readers come from different backgrounds ... do not leave out essential detail

3. It takes a long time. Leave time to write, review, revise.