Requirement Analysis and Specification Session 2005/ 2006 Pascal - - PDF document

Requirement Analysis and Specification

Session 2005/ 2006

Pascal Fenkam

Adm inistration & I ntroduction

Administrative details

Lecturer-in-charge

• Dr. Pascal Fenkam
• Argentinierstr. 8/ 1841, 3rd flloor

Office hours:

Thursday: 14h-15h

Studienassistenten

Daniel Fede Leo Brunnhofer Michael Halwax

Two mandatory group assignments Discussion via TUWIS 2 hours lectures (x 6)

RULES & REGULATIONS

Please be PUNCTUAL for all your classes. Switch off your m obile phones. Concentrate during lecture sessions. EXAM TI PS are given throughout the sessions Attendance is highly recommended. Behavior in Lectures: Listen & Ask!

Text Books

Managing Software Requirements: A Use Case Approach (Dean Leffingwell and Don Widrig), Chapters 8-13

Text Books

Problem Frames. Analyzing and Structuring software development problems (Michael Jackson), Chapters 1-8

Lecture Plan

Lecture Tutorial Group Assignments Final Examination

Course Assessment

• Coursework

Tutorial Group Assignment 45% Final Exam

55%

Total 100%

Your Responsibilities

• the lecture’s aim is to explain the syllabus

coverage for a topic and place it into context.

• It is not meant to tell you everything you need to

know about the topic.

• In order to gain sufficient depth of knowledge, you

are expected to read up other text and references and practice your analytical skills in solving the tutorial questions and case studies.

Dishonesty

We view any act of dishonesty with grave

concern.

Any student caught committing any form of

dishonesty will be deemed to have failed the examination.

Dishonesty includes plagiarism, misconduct

during examination and theft of other student’s work.

Q & A

Introduction to requirements engineering

Objectives

Introduce the notions of

requirements engineering (RE) system requirements

Put RE into a broader context of system

engineering

Introduce the notion of

processes and process models for RE

The Requirements Problem

• US expenses for IT applications

development: $ 250 billion/ year

• Standish Group:

31 % of projects are canceled before

ever get completed

22 % are completed but with cost and

schedule overrun or without meeting expectation

The Requirements Problem

• Requirements errors are the most common, most

serious problems and the most costly to fix.

• Standish Group: the three most cited factors:

Lack of user input (13 % of all projects) Incomplete requirements and specs (12 % ) Changing requirements and specs (12 % )

• A few skills can significantly reduce requirements

errors and improve software quality.

The Requirements Problem

Maintenance Acceptance test Unit test Coding Design Requirements Time

2 0 5 2

.1 -.2 .5 1

Cost of Requirements Errors

The Requirements Problem

• The requirements don’t reflect the real needs of

the customer for the system.

Result: Late nights, Systems are late,

unreliable, don’t meet customers needs, lot of canceled projects, com plete frustration.

• Requirements are inconsistent and/ or incomplete.
• It is expensive to make changes to requirements

after they have been agreed or/ and implemented

Redesign Recoding Retesting

Requirements Engineering

Softw are Requirem ents Features Needs Solution Dom ain Problem Dom ain

Requirements Engineering

• User Needs:

A reflection of the business, personal, or

• perational problem that must be addressed in
• rder to justify consideration, purchase, or use of

a new system

• Development teams need to understand true needs
• User Needs are often vague an ambiguous

I need easier way to understand the status of my

inventory/ library

I’d like to see a big increase in the productivity of

sales order entry

Requirements Engineering

• Feature: a service provided by the system that

fulfills one or more stakeholder needs

Each user must have an account in the library system Manual control of doors during fire emergency Linux compatibility

• Unfortunately, users often state neither features

nor their needs but something in between

I want a vehicle with ABS I need a new GUI-based order entry screen

• Users transform needs into believed features

Advantages: users are experts in their domains, such

features are easy to discuss and document.

Caveat: the feature may not be (and often is not) the

solution You are right, but you still lose!

Example of Features

• Define what the library system is required to do and

the constraints under which it is required to operate

• The system shall maintain records of all library

materials including books, serials, newspapers and magazines, video and audio tapes, reports, collections

• f transparencies, computer disks and CD-ROMs.
• The system shall allow users to search for an item by

title, author, or by ISBN.

• The system’s user interface shall be implemented using

a World-Wide-Web browser.

• The system shall support at least 20 transactions per

second.

• The system facilities which are available to public users

shall be demonstrable in 10 minutes or less.

Classes of custom systems

• Information systems

Primarily concerned with processing

information which is held in some database.

• Embedded systems

Systems where software is used as a

controller in some broader hardware system

• Command and control systems

A combination of IS and ES where the ES

provides information which is collected, stored, and used to make decisions via the IS

The systems engineering process

Software requirements engineering Requirements partitioning Architectural design System requirements engineering Sub-system development System integration

System validation

Requirements Engineering Process

Types of stakeholders

• Software engineers responsible for system development
• Software Architects, Designers, Testers, etc.
• System end-users who will use the system after it has

been delivered

• Managers of system end-users who are responsible for

their work

• Those managers who pay for the development of the

system

• External regulators who check that the system meets its

legal requirements

• Domain experts who give essential background

information about the system application domain

Process

A process is an organised set of activities which

transforms inputs to outputs

Process descriptions encapsulate knowledge and

allow it to be reused

Examples of process descriptions

Instruction manual for a dishwasher Cookery book Quality manual for software development

RE process - inputs and outputs

Agreed requirements System specification System models Requirements engineering process Stakeholder needs Organisational standards Domain information Regulations Existing systems information

RE process variability

• RE processes vary radically from one organisation

to another

• Factors contributing to this variability include

Technical maturity Disciplinary involvement Organisational culture Application domain

• There is therefore no ‘ideal’ requirements

engineering process

RE process activities

• Requirements elicitation

Needs and features discovered through

consultation with stakeholders

• Requirements analysis and negotiation

Requirements are analysed and conflicts resolved

• Requirements documentation

Requirements document are produced (including

specifications)

• Requirements validation

The requirements document is checked for

consistency and completeness

Spiral model of the RE process

Requirements elicitation Requirements analysis and negotiation Requirements documentation Requirements validation Informal statement of requirements Agreed requirements Draft requirements document Requirements document and validation report Decision point: Accept document

• r re-enter spiral

START

RE process problems

• Lack of stakeholder involvement
• Business needs not considered
• Lack of requirements management
• Lack of defined responsibilities
• Stakeholder communication problems
• Poor quality requirements documents

Process improvement

• Process improvement is concerned with

modifying processes in order to meet some improvement objectives

• Improvement objectives

Quality improvement Schedule reduction Resource reduction

Planning process improvement

• What are the problems with current

processes?

• What are the improvement goals?
• How can process improvement be introduced

to achieve these goals?

• How should process improvements be

controlled and managed?

Good practice for RE process improvement

• RE processes can be improved by the systematic

introduction of good requirements engineering practice

• Each improvement cycle identifies good practice

guidelines and works to introduce them in an

• rganisation

Examples of good practice guidelines

• Define a standard document structure
• Define policies for requirements management
• Use checklists for requirements analysis
• Use scenarios to elicit requirements
• Specify requirements
• Reuse requirements

Key points

• The requirements engineering process is a structured set
• f activities which lead to the production of a requirements

document.

• Inputs to the requirements engineering process are

information about existing systems, stakeholder needs,

• rganisational standards, regulations and domain

information.

• Requirements engineering processes vary radically from
• ne organisation to another.

Key points

• Requirements engineering process models are

simplified process description which are presented from a particular perspective.

• Human, social and organisational factors are

important influences on requirements engineering processes.

• Requirements engineering process improvement is

difficult and is best tackled in an incremental way.

• Requirements engineering processes can be

classified according to their degree of maturity.

Requirements Document

Requirements document

• The requirements document is a form al docum ent

used to com m unicate the requirements to customers, engineers and managers.

• The requirements document describes:

The services and functions which the system

should provide

The constraints under which the system must

• perate

Overall properties of the system i.e. constraints

• n the system’s emergent properties

Requirements document

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

Definitions of other systems which the system must

integrate with.

Users of requirements documents

• System customers

specify the requirements and read them to check

they meet their needs

• Project managers

Use the requirements document to plan and

manage the development process

• System engineers

Use the requirements to understand the system

being developed

• System test engineers

Use the requirements for testing

• System maintenance engineers

Use the requirements to understand the system

Adapting the standard

The IEEE standard is a generic standard which

can be applied to a wide range of requirements documents.

In general, not all parts of the standard are

required for all requirements documents

Each organization should adapt the standard

depending on the type of systems it develops

Requirements document structure

IEEE/ ANSI 830-1993 standard proposes a structure for

software requirements documents

Introduction

1.1 Purpose of requirements document 1.2 Scope of the product 1.3 Definitions of terms 1.4 References 1.5 Overview of the document

Requirements document structure

2.

General description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies

3.

Specific requirements; Covering functional, non- functional and interface requirements.

• 4. Appendices

Index

Guideline for Requirements Document

Define a standard document structure Explain how to use the document Include a summary of each requirement Make the document easy to read/ change Help readers find information

Writing requirements

• Requirements are usually written as

paragraphs of natural language text supplemented by diagrams

• Problems with requirements

use of complex conditional clauses which are

confusing

sloppy and inconsistent terminology writers assume readers have domain

knowledge

Writing essentials

• Requirements are read more often than they

are written. You should invest time to write readable and understandable requirements

• Do not assume that all readers of the

requirements have the same background and use the same terminology as you

• Allow time for review, revision and re-drafting
• f the requirements document

Writing guidelines

• Define standard templates for describing

requirements

• Use language simply consistently and concisely
• Use diagrams appropriately
• Supplement natural language with other

description of requirements

Requirements Elicitation

Objectives

• Describe the processes of requirements

elicitation

• Introduce a number of requirements

elicitation techniques.

Challenges of Requirements Elicitation

The “Yes, But” Syndrome

Software are abstract and often cannot be

experienced by users

Mechanical engineering has a well-defined

discipline of proof-of-principle models, sketches, mockups, models, prototyping for providing early feedback to customers.

This syndrome is human nature and integral part

• f application development. We must plan for it.

“Undiscovered ruins” Syndrome

The more you find the more you know remain. Be aware of the point where to stop searching.

Challenges of Requirements Elicitation

“User and Developer” Syndrome

Communication gap Users and developers are usually from

different worlds, have different motivations and objectives, drink different beers speak different languages.

We must learn to communicate more

effectively with these users

Elicitation activities

• Application domain understanding

i.e. the general area where the system is applied.

• Problem understanding

The details of the specific customer problem where

the system will be applied must be understood.

• Business understanding

i.e. how systems interact and contribute to overall

business goals.

• Understanding the needs and constraints of system

stakeholders

You must understand, in detail, the specific needs

• f people who require system support in their work.

Requirements negotiation

• Requirements discussion

problematical requirements are

discussed with the stakeholders.

• Requirements prioritization

Disputed requirements are prioritized to

identify critical requirements and to help the decision making process.

• Requirements agreement

Solutions to the requirements problems are

identified and a compromise set of requirements are agreed.

Elicitation techniques

• Techniques used to collect knowledge about

system requirements

• This knowledge must be structured
• Partitioning - aggregating related knowledge
• Abstraction - recognizing generalities
• Projection - organizing according to

perspective

• Elicitation problems
• Not enough time for elicitation
• Inadequate preparation by engineers
• Stakeholders are unconvinced of the need

for a new system

Elicitation techniques

Interviews Workshop Scenarios Observations and social analysis Requirements reuse Storyboarding

Interviews

• The requirements engineer or analyst

discusses the system with different stakeholders and builds up an understanding

• f their requirements.
• Types of interview

Closed interviews. The requirements

engineer looks for answers to a pre- defined set of questions

Open interviews There is no predefined

agenda and the requirements engineer discusses, in an open-ended way, what stakeholders want from the system.

Interviewing essentials

• Interviewers must be open-minded and should

not approach the interview with pre-conceived notions about what is required

• Avoid the “blank-page” syndrome.

Stakeholders must be given a starting point for

• discussion. This can be a question, a

requirements proposal or an existing system

• Interviewers must be aware of organizational

politics - many real requirements may not be discussed because of their political implications

Requirement Workshop

• Helps in building an effective and

committed team

• All stakeholder are involved and feel

important

• Forges an agreement between

stakeholders and developers

• Exposes and resolves political issues

Requirement Workshop

• Sell the concept to your colleagues

“Not another meeting”, “You’ll never get XX”,

• Target the right stakeholders
• High degree of professionalism in the

logistic preparation

• Send warm-up materials

Not too early, not too late

Requirement Workshop

• Facilitator:

Preferably from outside the organization Experienced with requirements

engineering issues

Team and consensus building skills Well respected by other team members

Requirement Workshop

• Facilitator Task:

Establish a professional and objective tone Starts and stops the meeting on time Establishes and enforce the rules Introduces the goals Manages the meeting and keep people on

track

Controls disruptive or unproductive behavior Makes sure that all stakeholders participate Makes sure that the focus remains on the

agenda.

Scenarios

• Scenarios are stories which show how a system might

be used. They should include

a description of the system state before entering the

scenario

the normal flow of events in the scenario exceptions to the normal flow of events information about concurrent activities a description of the system state at the end of the

scenario

• Scenarios are examples of interaction sessions of users

with the system

• Discovering scenarios reveals

possible system interactions facilities which may be required

Scenarios and OOD

• Scenarios are an inherent part of some object-
• riented development methods
• The term use-case (i.e. a specific case of

system usage) is sometimes used to refer to a scenario

• There are different views on the relationship

between use-cases and scenarios:

A use-case is a scenario A scenario is a collection of use-cases; each

exceptional interaction is represented as a separate use-case

Observation and social analysis

• People often find it hard to describe what

they do because it is so natural to them. Sometimes, the best way to understand it is to observe them at work

• Ethnography is a technique from the social

sciences which has proved to be valuable in understanding actual work processes

• Actual work processes often differ from

formal, prescribed processes

• An ethnographer spends some time
• bserving people at work and building up a

picture of how work is done

Ethnography guidelines

• Assume that people are good at doing their

job and look for non-standard ways of working

• Spend time getting to know the people and

establish a trust relationship

• Keep detailed notes of all work practices.

Analyze them and draw.

• Combine observation with open-ended

interviewing

Requirements reuse

• Reuse involves taking the requirements

which have been developed for one system and using them in a different system

• Reuse saves time and effort as reused

requirements have already been analyzed and validated

• Requirements reuse is still an informal

process; systematic reuse could lead to larger cost savings

Prototyping

• A prototype may be used for

experimentation and for pointing out strengths and weaknesses.

• Rapid development of prototypes is essential

so that they are available early in the elicitation process

Prototyping benefits

• Establishes feasibility and usefulness before

high development costs are incurred

• Essential for developing the ‘look and feel’
• f a user interface
• Can be used for system testing and the

development of documentation

• Forces a detailed study of the requirements

which reveals inconsistencies and omissions

Types of prototyping

• Throw -aw ay prototyping

Aims at eliciting the system requirements. The prototyped requirements are those which

cause most difficulties to customers and which are the hardest to understand.

• Evolutionary prototyping

Aims at quickly delivering a workable system

to the customer.

The prototyped requirements are those which

are well-understood and which can deliver useful end-user functionalities.

Prototyping costs and problems

• Training costs - prototyping may require

the use of special tools

• Developm ent costs - depend on the type
• f prototype being developed
• Extended developm ent schedules -

developing a prototype may extend the schedule

• I ncom pleteness - critical system

requirements are hard to prototype

Storyboarding

Purpose: gain an early reaction from

the users on the concept proposed for the application

Elicit early “Yes, but” reactions

Inexpensive User friendly, informal, and interactive Easy to create and modify Prevent the “blank-page” syndrome

Types of Storyboards

Passive storyboards

Tell a story to the user Includes sketches, pictures, screenshots. The analysts plays the role of the system and

walks the user though the storyboard

Active storyboards

Present a movie of a system that does not

exist yet

Animated, automated, animated slides, home

made movies, simulations

Interactive storyboards

User experience the system Simulations, mock-ups, interactive

presentations, live demos

Tips for Storyboarding

Don’t invest too much: customers may be

intimidated about making changes if it looks like a real product.

Make the storyboard easy to modify: if you don’t

change anything, you don’t learn anything

Don’t make the storyboard too functional otherwise,

some customers may want you to ship it.

Whenever possible, make the storyboard

interactive: the customer’s experience of use will generate more feedback and will elicit more new requirements.

Storyboard early, storyboard often, storyboard on

any project with innovative content.

Requirement Analysis

Requirements analysis

• The goal of analysis is to discover problems,

incompleteness and inconsistencies in the elicited requirements. These are then fed back to the stakeholders to resolve them through the negotiation process

• Analysis is interleaved with elicitation as

problems are discovered when the requirements are elicited

• A problem checklist may be used to support
• analysis. Each requirement may be assessed

against the checklist

Requirements interactions

• A very important objective of requirements

analysis is to

discover the interactions between requirements to highlight requirements conflicts and to highlight requirements overlaps

• A requirements interaction matrix shows how

requirements interact with each other. Requirements are listed along the rows and columns of the matrix

For conflicting requirements, fill in a 1

For overlapping requirements, fill in a 1000 For independent requirements, fill in a 0

Requirements negotiation

• Disagreements about requirements are

inevitable when a system has many

• stakeholders. Conflicts are not ‘failures’ but

reflect different stakeholder needs and priorities

• Requirements negotiation is the process of

discussing requirements conflicts and reaching a compromise

• In planning a requirements engineering

process, it is important to leave enough time for negotiation. Finding an acceptable compromise can be time-consuming

Negotiation meeting

• Information stage:

the nature of the problems is explained.

• Discussion stage:

the stakeholders discuss how to solve the

problems

All stakeholders with an interest in the

requirement should comment. Priorities may be assigned to requirements at this stage.

• Resolution stage:

actions concerning the discussed requirement

are agreed.

E.g. delete the requirement, modification to

the requirement, elicit further information.

Key points

• Requirem ents elicitation involves

understanding the application domain, the specific problem to be solved, the organizational needs and constraints and the specific facilities needed by system stakeholders.

• The processes of requirements elicitation,

analysis and negotiation are iterative, interleaved processes which must usually be repeated several times.

• There are various techniques of requirements

elicitation which may be used including interviewing, scenarios, storyboarding, prototyping, and participant observation, workshops, brainstorming.

Key points

• Prototypes are effective but may be expensive
• Storyboard are technically and cost effective
• Checklists are particularly useful as a way of
• rganizing the requirements validation process.
• Requirem ents negotiation is always necessary

to resolve requirements conflicts and remove requirements overlaps. Negotiation involves information interchange, discussion and resolution

• f disagreements.

Assignment I

Problem description: the aim of this project is to construct a machine (the software) to control an elevator called Catalina and where:

• There are a number n of elevator cabins, which travels between the floors
• f a building.
• There are two buttons on each floor to call the lift. These buttons

illuminates when pressed. The illumination is cancelled when the elevator visits the floor and the cabin is moving in the right direction.

• Inside each elevator cabin, there is a panel of buttons, one for each floor.

These buttons illuminate when pressed and cause the elevator to visit the corresponding floor. In addition, there are buttons for opening the doors of the cabin, closing them, and stopping the cabin.

• The illumination is cancelled when the corresponding floor is visited by the
• elevator. Requests are definitive, i.e., they cannot be cancelled, and they

persist; thus they should eventually be serviced.

Assignment I

• The arrival of the cabin at a floor is detected by a sensor.
• The software to be constructed may ask a cabin of the elevator to go up,

go down or stop.

• Each of the cabins has a sensor for detecting if somebody is entering or

leaving it. And in this case, the door must remain open as long as necessary.

• The door closes automatically after a predefined amount of time.
• When the elevator has no request to service, it should uniformly distribute

the cabins at the floors of the building. The cabins should remain at these destinations with doors closed and awaiting further requests.

• Each cabin has an emergency button that, when pressed, causes a warning

signal to be sent to the site manager. The whole elevator is then deemed “out of service“ and all cabins are blocked. Each elevator has a mechanism to cancel its “out of service" status.

Assignment I

Questions:

• Given that the above requirements are not complete, give the list of

stakeholders from which more requirements may be collected. The list should be as complete as possible.

• Describe five elicitation techniques that you would use for gathering

requirements from these stakeholders, plan them and design them. For instance, for an interview, you should list a complete set of devices that you need, the rooms where the interview will take place the person involved in this interview, the nature of the interview and the reason for choosing this type of interview, etc.

• Identify 15 user level use cases for Catalina and document them using use
• cases. The documentation should be done based on a well structured

requirement document and Requisite Pro used for this purpose. ( http: / / www-128.ibm.com/ developerworks/ downloads/ r/ rrp/ )

• Propose a requirements engineering process for an organization who

concentrates on building such elevators.

Administrative details

Assignment:

• http: / / www.infosys.tuwien.ac.at/ Teaching/ Courses/ RA/ .assignment/
• Deadline: 02.04.2006

Slides

• http: / / www.infosys.tuwien.ac.at/ Teaching/ Courses/ RA/ .slides/

Q & A