ser_ch5

© 2005 IAS, Universität Stuttgart 1

SER

5 Requirements Engineering

Software Engineering for Real-Time Systems

5.1 What are requirements?

5.2 Requirements Engineering

5.3 Specifying Requirements

5.4 Requirements Tracing

5.5 Summary


SER5.1 What are requirements?

Poor Requirements Management Puts Projects at Risk for Failure

Source: Standish Group 2000

success26%

late or over budget

46%

cancelled28%


SER

– Out of control• unclear requirements

• changing requirements

• unstable baselines

• ad hoc requirements management

• big gaps between customer expectations and actual product contents

– Poor estimates

• planning out of reach

• insufficient resources


Why Improving on Requirements Management?

– Inadequate management

• no commitments

• volatile or missing decisions

• plans not followed through

• subcontracting just happens

40..60% of all faults start out from requirements


SER

What are Requirements ?

– ambiguous

– not accomplishable

– over-determined

– incomplete

– inconsistent


List of wishes:

a bicycle like ‘Joe‘ a round ball a fast car watching the Simpsons a veteran car

List of wishes:

a bicycle like ‘Joe‘ a round ball a fast car watching the Simpsons a veteran car

Requirements typically are:



Terminology

A requirement is

– 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 product or product component to satisfy a contract, standard, specification, or other formally imposed documents.

Requirements management is a systematic approach to

– Eliciting, organizing, and documenting all the requirements (functional, non-functional, non-technical) of the system, and

– Establishing and maintaining agreement between the customer/user and the project team on the changing requirements of the system

Source: IEEE 610.12-1990



Viewpoints on Requirements

– Description of an attribute

– Description of a functionality

– Description of a constraint

– The sum of all requirements defines the scope of the product

– Described in a way to allow validating whether the requirement is actually realized.

functional requirement

Test cases

The requirements description determines, what a product “should be able to do” and “what it looks like”,

NOT : how it is realized.

nonfunctional requirement



Characteristics of requirements (1)

– Unambiguous -- Every statement has one interpretation. Terms are clear and well defined.

– Complete -- All significant requirements are included. No items have been left for future definition.

– Verifiable -- All features specified as part of the project have a corresponding test to determine whether they have been successfully delivered.

– Consistent -- Conflicting terminology, contradictory required actions, and impossible combinations are notably absent.

– Modifiable -- Redundancy is absent; index and contents are correct.

– Traceable -- Each referenced requirement is uniquely identified.

– Correct -- Every stated requirement represents something required of the system to be built.

Potential conflict: comprehensible requirements in natural language might not fit into this list of characteristics.


SER

Characteristics of requirements (2)


– Reference book for developers, testers, customers, users, marketing, etc

• determining of project relevant contents and terminology

• classification

• keywords

When describing technical requirements you can distinguish between:

– functional requirements(What is the software system that is being developed supposed to do?) classification

– non functional requirements(Which attributes apply to the functional requirements?)


SER

Functional requirements

– definition: input

– definition: output

– data models

– definition: functions, processes, events

– definition: interfaces



SER

Nonfunctional requirements

– performance requirements• amount of users

• extent of data

• response times

• process frequency

– quality requirements• dependability

• Safety

• security

– implementation requirements• methods

• guidelines

• acceptance

• documentation

• Resources (skills, certification)



SER

Example: RTOS

– Embedded systems often ask for soft or hard real-time requirements. During requirements engineering, it’s the task of the systems engineer to determine how this translates into system specs (cost, effort, skills!)

– On top of ensuring these requirements is a real-time OS (RTOS). RTOS form the foundation of an embedded system.

– To be considered real-time, the RTOS must provide dependability, predictability, simultaneity, and timeliness.

– Precision timing in a RTOS is achieved by (selection criteria)• Utilizing asynchronous threads (I.e., Multiple threads of execution

(multi-threaded); Priority scheduling to meet critical thread deadlines; Low/deterministic context switching time; Low/deterministic inter-thread communication time)

• High resolution deterministic timers (I.e., Needed to support periodic threads; Needed for system timeout)

• Configurability (I.e., Many real-time systems are also embedded, which places limitations on the amount of memory, type of processor etc.)



SER

Classification of Requirements


Requirements

Non-Technical

Technical

Functional Non-Functional

external- User interface- Interworking

internal- Load balancing- Power supply

external- Performance- Reliability- Usability

internal- Testability- Maintain-ability

Cons-traints

- Standards- Environmental- Organization

Proper-ties

- Cost- Marketing

Source: Ebert, 1998



Functional requirements are accompanied with nonfunctional and nontechnical requirements

Z 1

Z 2

Z 3

Z 4

D

IN

§

functional requirements

non functional requirements, regulations, standards

what ? what has to be considered ?

user requirement specification/system requirement specification

Constraints,attributes

VED

TÜV


SER

Difference between functional and non functionalrequirementsillustrated by the example of a heating regulator

Functional requirements:

In dependence of the measured external temperature TA and the adjusted desired temperature TS a regulation of the boiler temperature TK should be realized. The regulation is realized by turning the burner fan on or off :

State of the burner = function (TA, TS, TK )

The deviation may not exceed 2° C



SER

a) The realization of the regulator has to be achieved with a micro computer using the programming language Ada.

b) The heating regulator has to run with a failure probability of maximal 0,01; given a maintenance interval of one year.

c) During the adjustment of the heating regulator the relevant rules taken from the “Regulation for Heating Systems“ (HeizAnIV - 22.09.1978) have to be taken into account.

d) Due to the related costs only analog-digital converter with low resolutions (10 bits) can be used.


Further Attributes:non functional requirements


SER







5.5 Summary


SER

Goals of requirements engineering

– support determining the requirements

– support the software / systems engineers in editing the requirements

• specify

• classify

• put in a hierarchical order

• trace

– support validating the system (quality assurance)


interface

Test starts already in early stages


SER

Agreement on What the System Should Do


The Goal

ValidationRequirementsVerification

CustomerUser Community

Requirements

System To Be Built


SER

Conceptual formulation versus conception = WHAT versus HOW


professor student

requirements specification

“That‘s what I want..."

Concept (design specification)

“That‘s how I want to do this"

customer supplier


SER

Viewpoint-oriented elicitation

Stakeholders represent different ways of looking at a

problem or problem viewpoints

This multi-perspective analysis is important as there is

no single correct way to analyse system requirements



SER

Example: ATM viewpoints

– Bank customers

– Representatives of other banks

– Hardware and software maintenance engineers

– Marketing department

– Bank managers and counter staff

– Database administrators and security staff

– Communications engineers

– Personnel department



SER

Typical problems for system analysts

– vague formulations

– vague terms

– incomplete descriptions


First of all the system analyst has to understand the conceptual formulation as described by the customer


SER

Activities during the initial phases of a project:

– Analysis of the present state of the technical process, of already available devices or software as well as of organizational circumstances


Req

uire

men

tsE

ngin

eerin

g – Determination and description of the conceptual formulation and of the user requirements for the automation system

– Analysis of the conceptual formulation, composition (design) of a technical solution, validation of this solution with CASE systems

– project planning (incl. estimation of efforts)


SER

Requirements Engineering


proj

ect

plan

ning

technical process

SW/ HW system design

definition of requirements

(what?)

technical Solution(how?)

may be analysis of present state


SER

Requirements Engineering Activities


RequirementsEngineering

collection analysis allocation

tracing / change management

specification / verification


SER

Top Risks of Requirements

– Overlooking a crucial requirement

– Inadequate customer representation

– Modeling only functional requirements

– Not inspecting requirements

– Attempting to perfect requirements before beginning construction

– Representing requirements in the form of designs


Source: Lawrence, Wiegers, Ebert, 2001


SER

Manage Risks

– Categorize• Group requirements, permitting a higher-level understanding of

relationships and dependencies.

• Consistently apply a specification template (e.g. use cases, IEEE 830, IEEE 1233).

– Organize

• Use automated tools to assist in understanding and tracing of requirements from inception to allocation to delivery.

• Apply strict change management.

– Prioritize

• Determine the order of consideration based on criticality of need and level of associated risk.

• Implement in increments following the priorities. Descope lowest priority features.



SER

Requirements Engineering Process


Analyze: formulate, classify,put requirements in hierarchical order

Trace requirementsand validate the system versus requirements

Collect and specify requirements

Allocate requirements


SER

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



SER

Scenario descriptions

– System state at the beginning of the scenario

– Normal flow of events in the scenario

– What can go wrong and how this is handled

– Other concurrent activities

– System state on completion of the scenario



SER

Use cases

– Use-cases is a scenario based technique in the UML which 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

– Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system



SER

Library use-cases


LibraryUser

Lending services

User administration

Catalogue servicesSupplier

LibraryStaff


SER

Successful Negotiation Means Win-Win

– To protect the supplier:• Express disagreement and unrealistic conditions openly.

• Offer compromise approaches, once needs are understood.

• Have a signed contract with requirements. Agree on clear and reasonable acceptance criteria.

• Include a software key that will operate after the date of contracted software acceptance.

• State in the contract that the supplier owns the code until final payment.

• Clearly agree on liabilities and support after handover.

– To protect the client:

• Clearly state that payment will be provided only for systems that meet the agreed upon functionality.

• Require milestone presentations of progress for continued funding.

• Provide a realistic and precise expectation of functional and nonfunctional requirements (e.g. reliability).



SER







5.5 Summary


SER

Specifying Requirements

The definition of a requirement specification following international standards (see ch. 5.5):

In a user requirements specification the user orientated requirements incl. the attributes, constraints, etc are described. This data must be quantifiable and testable.

The requirements specification defines WHAT KIND OF task is solved.

The requirements specification is created by the client or on his behalf. It serves as bidding, offer and/ or basis.



SER

Create the requirements specification

1. Determine the requirements specification

– user / stakeholder requirements

– system requirements

– External / environmental inputs

2. Writing the requirements

– communication and decision between clients and contractors


3. Classification (and prioritization) of the requirements

– functional requirements

– data requirements

– quality requirements

– performance requirements

– implementation requirements

– organization requirements

regulations, norms

safety requirements

nice-to-have-requirements


SER

4. Putting requirements in a hierarchical order


5. Check requirements

– unambiguousness

– completeness

– verifiability

– consistency

– modifiability

– comprehensibility

– reliability / practicability


SER

Structuring requirements

Advantages:

– better manageability

– better understandability

– identifiable requirement

– comprehensibility

– basis of a contract


descriptive text

abcdefg 8427983443 5923850 934534 464 756lkjklj jk jk lklk lököklökölgkd

fgj gjfk glfl jgk jjfgk ghg jkj df g#3423 345 67 79345 67428934534 6867 2468 23423 57 6862342 575 789345 67 89hjdcbcdsfsd sdf fghghjh gg ggj hgjgfgh gfhf fghfgfghgf

fhfghf gfhf fz423 /T/( &/

$% /&( /%(/%&/9234 &/( /()2342 23423 45643453546749876 46 46

wkrlw35348 34593 4746

34534 35 4656 55675 57575 575 57567 576577575 57 5757 568685756756 5765 567567575675

user requirements

user constraints

capabilities

attributes

boundary conditionsconstraints


SER

Structuring requirements

Introduction

General description

Specific requirements

Appendices

Index


This is a generic structure that must be instantiated for specific systems. See Standards (ch. 5.5) for further extensions.


SER

Requirements Specification structure

Introduction

Glossary

User requirements definition

System architecture

System requirements specification

System models

System evolution

Appendices

Index



SER







5.5 Summary


SER

Requirements Trace To Many Project Elements



SER

Requirement tracing

– Traceability is concerned with the relationships between requirements, their sources and the system design

– Source traceability

• Links from requirements to stakeholders who proposed these requirements

– Requirements traceability

• Links between dependent requirements

– Design traceability

• Links from the requirements to the design



SER

“Requirement - Feature Matrix“ according to Boehm


Feature

Requirement

F1 F2 F3 ...

R1 X11 X12 X13

R2 X21 X22 X23

R3 X31 X32 X33

.

.

.

Requirements FeaturesMatrixRequirements FeaturesMatrix


SER5.4 Requirements Tracing

Xij = A ... examined and consequences accepted

B ... not examined yet

O ... without consequences (irrelevant)

Di ... reference to designing decision

Ri ... reference to another requirement

designing decision verbal description

D1

D2

comment 1

comment 2

.

.

.

.

.

.


SER

Traceability between Work Products


requirement ...requirement ...requirement ...

Requirements specification

1."sections" referring to requirement ... requirement ... fulfils ... substitute ...

Analysis Model

actionsdatainterfacesprocesses...

design

activitiesproject participantsresourcesproducts...

project management


SER5.4 Requirements Tracing

project management

ACTIVITY SWCE-3-development.PROBLEM: “During this development stage the SWCE 3 is being developed...“TECHNICAL-FRAMEWORK:

PLANNED-SECTIONS: P1.1.1.1.1. “SW configuration entity 1”,P1.1.1.1.1.1. “SW component 1”,P1.1.1.1.1.2. “SW component 2”.

PLANNED OBJECTS: SWCE 1, SW component 1, SW component 2.PREDECESSORS: segment specification-Segment 1.

ACTIVITYEND

ACTIVITY SWCE-3-development.PROBLEM: “During this development stage the SWCE 3 is being developed...“TECHNICAL-FRAMEWORK:

PLANNED-SECTIONS: P1.1.1.1.1. “SW configuration entity 1”,P1.1.1.1.1.1. “SW component 1”,P1.1.1.1.1.2. “SW component 2”.

PLANNED OBJECTS: SWCE 1, SW component 1, SW component 2.PREDECESSORS: segment specification-Segment 1.

ACTIVITYEND

...1.1.1.1.1. “SW configuration entity 1”

“This system component‘s task is to...”

1.1.1.1.1.1. “SW component 1”“This software component‘s task is to...”REQUIREMENT 10001 (1) ...REQUIREMENT 10002 (2) ...

1.1.1.1.1.2. “SW component 2”“This software component‘s task is to...”REQUIREMENT 10001 (3)REQUIREMENT 10002 (1)...

...1.1.1.1.1. “SW configuration entity 1”

“This system component‘s task is to...”

1.1.1.1.1.1. “SW component 1”“This software component‘s task is to...”REQUIREMENT 10001 (1) ...REQUIREMENT 10002 (2) ...

1.1.1.1.1.2. “SW component 2”“This software component‘s task is to...”REQUIREMENT 10001 (3)REQUIREMENT 10002 (1)...

analysis model designACTION SWCE 1.DESCRIPTION:

PURPOSE: “...DESCRIPTIONENDDECOMPOSITION:

(/ SW comp. 1, SW comp. 2 /)ACTIONEND

ACTION SW comp. 1DESCRIPTION:...FULFILS: REQ. 10001 (3)

REQ. 10002 (1)

ACTION SW comp. 1DESCRIPTION:...FULFILS: REQ. 10001 (1)

REQ. 10002 (2)...


SER

Requirements change

The priority of requirements from different viewpoints changes during the development process

System customers may specify requirements from a business perspective that conflicts with end-user needs

The business and technical environment of the system changes during its development (this is most frequent reason for change)

• Typically ca. 2..3% per month!



SER

Requirements Change Management

Requirements change 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



SER

Tool support

Requirements database

– Requirements should be managed in a secure, managed data store

Change management

– The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated

Traceability management

– Automated retrieval of the links between requirements



SER







5.5 Summary


SER5.5 Summary

Summary

– Requirements engineering includes collection, analysis, allocation, specification, verification, tracing and managing change of requirements.

– Requirements analysis is iterative involving domain understanding, requirements collection, classification, structuring, prioritization and validation

– Systems have multiple stakeholders with different requirements and different views on the same system to be developed.

– Most frequent error: to give the customer what she needs and not what she wants.


SER

Standards

– IEEE 1220: Systems Engineering Process

– ISO 15288: System Life Cycle Processes

– ISO 12207: Standard for Software Life Cycle Processes

– CMM, CMMI, ISO 15504: Software Process Improvement and Capability Determination

– SW-CMM: Software Engineering Capability Maturity Model

– SE-CMM: Systems Engineering CMM

– CMMI: Capability Maturity Model Integration

– IEEE 1233: Guide for Developing of System Req. Specifications

– IEEE 830: Recommended Practice for SW Req. Specification

5.5 Summary


SER

Internet Resources

– Requirements Engineering / Management web links• http://www.shu.ac.uk/tfre/web.links.html

– Requirements Engineering hotlist• http://www.cc.gatech.edu/computing/SW_Eng/hotlist.html#requirements

– IEEE Task Force on Requirements Engineering• http://www.shu.ac.uk/tfre/welcome.html

– RENOIR (Requirements Engineering Network Of Int. cooperating Research groups)• http://www.cs.ucl.ac.uk/research/renoir/

– Requirements Engineering Journal • http://rej.co.umist.ac.uk/

– Intern. Council on Systems Engineering - Requirements Working Group • http://www.incose.org/rwg/

– Guidance to select a requirements management tool• http://www.incose.org/toc.html , http://www.incose.org/tools/tooltax.html

– Practical examples for requirements documents, inspection checklists, req. prioritization • http://www.processimpact.com

– Estimation tools (and more)• http://www.methods-tools.com

5.5 Summary


SER

Further Information

Software Requirements (Best Practices)

by Karl E. Wiegers /$34.99/ Paperback - 368 pages /(September 1999)

Microsoft Press; ISBN: 0735606315

Well-written introduction to requirements engineering. Focus especially on practitioner. Excellentchapter on tools for requirementsengineering.

5.5 Summary

ser_ch5

Documents