101 uses of requirements a talk on the reasons for engineering requirements
This presentation is the property of its rightful owner.
Sponsored Links
1 / 49

"101 Uses of Requirements" A talk on the reasons for engineering requirements PowerPoint PPT Presentation


  • 38 Views
  • Uploaded on
  • Presentation posted in: General

"101 Uses of Requirements" A talk on the reasons for engineering requirements. Ian Alexander. System Architect User Group, 2001. System. Subsystem 1. Subsystem 2. Subsystem 3. Assembly c. Assembly a. Assembly b. Software Program y. Hardware Device x.

Download Presentation

"101 Uses of Requirements" A talk on the reasons for engineering requirements

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


101 uses of requirements a talk on the reasons for engineering requirements

"101 Uses of Requirements"A talk on the reasons for engineering requirements

Ian Alexander

System Architect User Group, 2001


Requirements aren t only for software

System

Subsystem 1

Subsystem 2

Subsystem 3

Assembly c

Assembly a

Assembly b

Software Program y

Hardware Device x

Requirements Aren't Only for Software

Systems can be composed of subsystems of any type


Different types of requirement

Engineered

System

World

satisfies

satisfies

Different Types of Requirement

User

Requirements

System

Requirements

System Design/

Architecture

Desired Resultsto overcome Problemsin the World

Engineered Solutionsusing new and existing Systems

… need to be thought about differently


Ur activities

UR Activities

  • Identify Business Objectives

    • Why develop anything?

  • Identify Stakeholders

    • Who is involved?

  • Obtain Viewpoints

    • What are they concerned about?

    • Do they conflict?

  • Resolve Conflicts?

  • Identify Scenarios

    • What results do people want?


Objectives example

Must not conflict!

Must not conflict!

Objectives Example

  • "To become the market leader in small-household burglar alarms"

  • "To make steadily growing annual income from alarm sales, maintenance, and monitoring"

Clear, Simple, Truthful – with many implied requirements


Users systems actors stakeholders

Users, Systems, Actors, Stakeholders

Stakeholders

Actors

Users

Systems


Identify stakeholders

Identify Stakeholders

  • Initial contact will usually indicate people to talk to, their roles and interests

  • Stakeholders include direct system users and indirect interests, e.g. regulators and standards bodies

  • Stakeholders may themselves suggest other people who ought to be consulted …


Example viewpoints

Example Viewpoints

Burglar Alarm Viewpoints:

Householder – want to be safe in my house, not lose valuables

Maintenance Engineer – want a job; want alarm to be easy to diagnose and repair

Police – want to reduce crime; no nuisance from ringing alarms

Shareholder – want annual income based on alarm sales and contracts to monitor & maintain alarms

IEE, BSI – want systems to conform to standards, be electrically safe


Types of viewpoint

Types of Viewpoint

These can be Actors

System

Direct

Operator

Maintenance

Viewpoint

Engineering

Standards

Regulatory

Indirect

Organisation

These influence our system from outside

Environment

After Sommerville & Kotonya


Direct and indirect viewpoints

Direct and Indirect Viewpoints

  • Direct viewpoints

    • Interact directly with the System

    • Clients who receive services

    • e.g. Operators & Other Systems

  • Indirect viewpoints

    • Do not interact directly with the System

    • Have an ‘interest’ in services delivered by System

    • Create constraints on System

    • e.g. engineering standards, industry regulator


Conflict resolution

Conflict Resolution

  • Disagreements about requirements are inevitable when a system has many stakeholders. Conflicts are not ‘failures’ but reflect different stakeholder needs and priorities

  • Expect to have to discuss requirements conflicts and reach a compromise that all stakeholders can agree to

  • Important to leave enough time for negotiation. Finding a compromise is often time-consuming


Capturing scenarios

token

Capturing Scenarios

  • A workshop can represent a sequence of tasks directly by role-play

  • Users often understand processes for the first time

next user states

role, activity…

user states role & activity,

identifies next user(s),

throws token(s)


99 uses for scenarios

Scenarios show what results systems should deliver

So they are the natural way of checking that systems do what they should

And defining how systems should be used & maintained

And teaching people to use them

Acceptance Test Scripts

System Usage

Scenarios

System Test Scripts

System Operations

Manual

System Maintenance

Manual

Training

Courses/Manuals

99 Uses for Scenarios...

Problem Domain

Scenarios


Eliciting functional and non functional requirements use misuse cases

threatens

Driver

Driver

Driver

Steal the Car

Car Thief

Car Thief

Eliciting Functional and Non-Functional Requirements: Use & Misuse Cases

Drive the Car

includes

mitigates

includes

Lock the Car

threatens

Short the Ignition

includes

mitigates

Lock the Transmission

Use Cases for 'Car Security'


Capturing exceptions

Exceptions

Not set

Alarm failed

Wrong PIN

Exceptions

Not shut

Exceptions

Alarm failed

Animal in house

Owner/friend in house

Wind triggers alarm

Capturing Exceptions

Set Alarm

Shut Door

Watch for Intrusion


Gathering capturing eliciting

Gathering, Capturing, Eliciting

  • is about understanding business & system context

  • creates user requirements and constraints

  • many possible approaches and methods

Do requirements exist before

you go out to capture them?


Sources of requirements

Interviews with users

The system’s environment

Business objectives

Marketing requirements

Contractual obligations

Working in user environment

Analogous or existing systems

Change suggestions, problem reports

User modifications

User group meetings

Workshops

Prototypes

Studies

Innovation work

Questionnaires

Consultants & Trainers

Observation / Fieldwork

Sources of Requirements


Validating requirements are we about to build the wrong system

Validating Requirements – Are we about to build the wrong system?

  • Certify that described system is the wanted system

  • Check requirements document for

    • Completeness and consistency

    • Conformance to standards

    • Method of testing agreed

  • Ensure freedom from

    • Requirements conflicts

    • Technical errors

    • Ambiguities

Best to find out before

you spend $1000M


Requirements review

Plan the Review Cycle

Obtain Review Comments

Classify & Sort Comments

Conduct Review Meeting

All reviewers work from same version

Update

Requirements Document

Execute Agreed Actions

Pre-review Baseline

Post-review Baseline

Requirements Review

Approved version


Review checks

Review Checks

  • Understandable

    • Can readers of the document understand what the requirements mean?

  • Stated Once

    • Is information unnecessarily repeated?

  • Complete

    • Any missing requirements? Any information missing from individual requirement descriptions?

  • Unambiguous

    • Are all terms clearly defined?

    • Could readers from different backgrounds interpret the requirements differently?


Review checks1

Review Checks

  • Consistent

    • Different requirements free from contradictions?

  • Organised

    • Document structured sensibly?

    • Related requirements grouped together?

  • Conforms to standards

    • Do individual requirements and whole requirements document conform to standards? Are departures from the standards fully justified?

  • Fully Traced

    • Requirements unambiguously identified?

    • Links to all related requirements?

    • Links to justifications?


Requirements checklist

Requirements Checklist

  • Is each requirement uniquely identified?

  • Are all specialised terms defined in the glossary?

  • Does each requirement stand on its own?

  • Are terms used consistently?

  • Are there any contradictions?

  • Are all mentioned facilities described?

  • Are all related requirements grouped or cross-referenced?

  • Can we build it?


Sr activities

SR Activities

  • Trace Between Items

  • Model Desired Behaviour

  • Define Constraints

  • Specify Requirement Attributes


Traceability

Traceability

  • Traceability is primarily to help assess the impact of requirements change (tracing forwards to design)

  • And to demonstrate complete satisfaction of requirements (tracing backwards from design)

  • Traces link requirements to other system items

  • Traces have many other uses and purposes:

    • to support verification (linking test steps to requirements and other items)

    • to link to reference documents

    • to link terms to their definitions

    • … and so on.


Backwards forwards traceability

Backwards/forwards Traceability

go forwards to assess impact of a change

System Design

System Specifications

User Requirements

go backwards to trace origins of a component

Logical links can be followed in either direction


Traceability example

Traceability Example

Impact of requirements on design (in another document)

is found from traceability links


Example types of traceability

Example Types of Traceability

  • satisfies

    • Links an item back to its sources (such as a requirement). Each system specification and design element must trace back to at least one source

  • defines

    • Links a definition to a term being used with a particular meaning within the project. Should be a 1:1 mapping.

  • verifies

    • Links a verification (usually a test) item back to a requirement that it helps to verify. (Note that several tests may be needed for one requirement, and that one test may help to verify many requirements.)

  • ...and many others (constrains, depends on, …)


Information model of requirement traceability

Information Model(of requirement traceability)

  • Explicitly named relationships

  • Relationship has a type and a direction

  • Simple mapping between user concepts and data structures

Typed, Directional Traceability Relationship

Document / Data Structure


Traceability matrix

Traceability Matrix


Traceability graph back to back trees

Traceability Graph (Back-to-Back Trees)


Traceability making sure you build what the users want

Traceability - Making Sure You Build What The Users Want

  • Engineers and Reviewers have to be able to refer to each requirement uniquely, but change is inevitable and continuous – making tracing difficult

  • Requirements are more stable than implementations, but compatibility and portability requirements are therefore often volatile

  • Tool support becomes essential when projects are any of the following: large, distributed, long-lived, safety- or mission-critical, in product families or multiple versions, or subject to change


Model system behaviour objectives

Model System Behaviour - Objectives

  • To explore the solution, avoiding commitment to any specific design

  • To Show what the system must do, but not how

  • To Model the desired behaviour of the system

  • To Map between the World and the Machine

    • between the user requirements and the system design

  • Method: constrain the solution space with precise specifications. Often called ‘system requirements’ as distinct from ‘user requirements’

  • Focus on functions/constraints that must be flowed down to the physical design to meet the user requirements

  • Leave freedom for designers to decide how to partition into sub-systems


System behaviour modelling defines exactly what is needed

System behaviour descriptions

End-to-end scenarios/threads

Timing/sequencing of functionality

Requirements for parallelism/concurrency

Data and/or material flows

Flow of control

Conformance to mathematical models/algorithms

Performance requirements

System constraints and ‘ilities’

Interactions with external systems

Other modes of operation:

Fall-back/reversionary

Abnormal, degraded & emergency

Recovery

Start, stop, reset, warm-up,…

Test modes

Instrumentation or recording

Training

Safety interlocks, inhibits, overrides,…

System Behaviour ModellingDefines Exactly What Is Needed


What to model and when

What to Model, and When

To Describe:Model with:

Big Picture, Actors’ StoryAgent Interactions or Use Case Summary

Sequences of EventsScenarios, Use Casesfirst for business transactions,then for system threads

What can happen, whenState Transitionsfor complex subsystems

Detailed structure of dataEntity-Relationships or for complex structuresObjects & Attributes

Partitioning into subsystemsObjects & Messageswith interfaces


Traditional versus uml

TraditionalversusUML

[Context]Context Diagram Agent Interactions, orUse Case Summary Diagrams

[Scenarios] Jackson Trees, Flowcharts Use Case text (not diagrams),(Dataflows are unsuitable) Activity Diagrams +/- Swimlanes

[States] State Transition DiagramsState Diagrams

[Data] Entity-Relationship Diagrams Objects & Attributes

[Architecture]Procedure Calling Trees, Objects & Messages, Informal Box-and-Line Object Sequence DiagramsArchitectureDiagrams, Dataflows


Define constraints

Define Constraints

  • Capture requirements that are not functions but which constrain the desired system in any way

  • Link to specific functions where possible

  • Some constraints are global, e.g. end-to-end performance targets

  • No perfect universal way to classify constraints – but may be helpful to think through a checklist


Types of constraint including ilities

Types of Constraint(including ‘ilities’)

Constraints

Product

Process

External

Usability

Delivery

Legal

Reliability

Implementation

Safety

Economic

Efficiency

Standards

Interoperability

Performance

Many other types

Capacity

After Sommerville & Kotonya


Priority other attributes

Priority & Other Attributes

  • Database tracks each item, allowing audit and tracing

  • User-defined attributes typically include Status and Priority among others


Control changes

Control Changes

  • Change comes from many sources – detected errors, user wishes, new technology opportunities, competition, …

  • Uncontrolled change derails projects

  • Ideal is to permit change in manageable increments at predictable cost

  • So, you need a change management policy


Concepts of requirements engineering

newly elicited requirements

agreed versions, traces, progress

Concepts of Requirements Engineering

  • Requirements Engineering consists of two related streams of activity:

    • Requirements Development (Elicitation, Analysis, & Modelling)

    • Requirements Management (Identification, Configuration, Prioritisation, Traceability)

Requirements Elicitation, Analysis, & Modelling

Requirements Management

  • Requirements Development creates and interprets requirements

  • Requirements Management organises and keeps track of them


Manage the requirements

Manage the Requirements

R

e

q

.

q

u

e

r

y

R

e

q

.

b

r

o

w

s

e

r

s

y

s

t

e

m

Requirements Database

T

r

a

c

e

a

b

i

l

i

t

y

R

e

q

u

i

r

e

m

e

n

t

s

import/export

s

u

p

p

o

r

t

s

y

s

t

e

m

d

o

c

u

m

e

n

t

Traceability

Matrix

C

h

a

g

e

c

o

n

t

r

o

l

n

R

e

p

o

r

t

g

e

n

e

r

a

t

o

r

s

y

s

t

e

m

Metrics,

Graphs, etc

R

e

q

u

i

r

e

m

e

n

t

s

r

e

p

o

r

t


Managing the requirements

Managing the Requirements

  • Guaranteeing a solid basis for projects

  • Receives the products of Elicitation & Modelling

  • Consists of 3 quite different kinds of activity

    • Fine-Grained Configuration Management (CM)

    • Coarse-Grained CM

    • Fine-Grained Engineering Decision Support


Fine grained configuration management cm

Fine-Grained Configuration Management (CM)

  • Uniquely identifies every requirement

    • solid basis for review

      e.g. “reqt #123 is ambiguous, please change it”

    • foundation of traceability

      e.g. “reqt #123 is satisfied by design items #345, #346”

    • only possible basis for managing versions and releases

      e.g. “reqt #123 is

      • optional in version 1.0

      • mandatory in version 2.0”

  • Must be available within RM toolkit (however it is done)

  • Must be rock-solid


  • What is a requirements release

    What is a Requirements Release?

    • A Release is a group of Requirements to be developed together

    • The resulting (increment of) functionality is typically released to users as a new Product Version

    • Can you just put whatever the users want most in Release 1.0 ?

      No!

    • Some Requirements depend on others

      • no point being able to send colour images to cellphones until colour screens exist

    • So a Release is a Consistent Interdependent Set of Requirements

    • Later Releases can build on earlier ones

    • Should (in theory) be easy if Life-Cycle is Incremental

    • But since development is often Evolutionary, Release Planning can be hard


    Coarse grained configuration management cm

    Coarse-Grained Configuration Management (CM)

    • Baselines whole sets of requirements/project documents

      • solid basis for reviews, contracts, product releases

        e.g. “Baseline for System Requirements Review (SR/R) contains

        • BR v2.1

        • SR v1.0

        • AT v1.3

        • ST v1.0”

          e.g. “We promise to deliver the system specified in SR v1.0 at end of Stage 2”

    • builds on the fine-grained definition of what exactly is in each version of each document

  • CM should therefore be closely integrated with RM toolkit

  • Must keep the document versions securely


  • Fine grained engineering decision support

    Fine-Grained Engineering Decision Support

    • Prioritising each requirement

      • rational basis for trade-offs and hard decisions

        e.g. “reqt #124 is nice but not vital”

    • Tracing each requirement

      • rational basis for cost estimation

        e.g. “reqt #124 leads to design items costing £xyz”

      • rational basis for trade-offs

        e.g. “reqt #124 is not vital; deleting it will save £xyz”

    • Specifying which requirement belongs to which Version / Release

      • firm basis for agreement between customer & developer

        e.g. “reqt #124 waits till v3”


    And requirements are the foundation of v v

    User

    Requirements

    Definition

    System

    Requirements

    Definition

    System Design

    Definition

    Sub-system

    Requirements

    Definition

    Sub-system

    Definition

    Building Block

    Requirements

    Definition

    Building Block

    Design

    Building Block

    Manufacture

    And Requirements are the foundation of V&V!

    Validation (that we have the right requirements for the next version)

    Operational

    Acceptance

    Verification (that the system does meet its requirements)

    Operational

    Trials

    System

    Testing

    Verification

    (of each sub-system)

    System

    Integration

    Sub-system

    Testing

    Validation(that we have the right requirements now)

    Verification

    (of each building block)

    Sub-system

    Integration

    Building Block

    Testing

    Building Block

    Commissioning


    101 uses of requirements a talk on the reasons for engineering requirements

    Soft SystemsEngineering

    Human Factors Engineering

    Software Engineering

    Enterprise

    Management

    SystemsEngineering

    Verification Engineering

    Project Management

    Hardware Engineering

    Requirements Engineering


    101 uses for requirements

    101 Uses for Requirements?

    • No, there are many more than that!

    • The essential foundation of every project

    • The little rudder that guides the ship

    • Why? Who? When? What? How Much?

    • Impossible without.


  • Login