Requirement Analysis and Specification

Session 2005/2006

Pascal Fenkam

Administration&Introduction

Administrative details

Lecturer-in-chargeDr. Pascal Fenkam

Argentinierstr. 8/1841, 3rd flloor

Office hours:Thursday: 14h-15h

StudienassistentenDaniel FedeLeo BrunnhoferMichael Halwax

Two mandatory group assignmentsDiscussion via TUWIS2 hours lectures (x 6)

RULES & REGULATIONS

Please be PUNCTUAL for all your classes.Switch off your mobile phones.Concentrate during lecture sessions.

EXAM TIPS are given throughout the sessionsAttendance 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 TutorialGroup AssignmentsFinal Examination

Course Assessment

Coursework

Tutorial Group Assignment 45%Final Exam 55%

Total 100%

Your Responsibilitiesthe 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

ObjectivesIntroduce 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 completed22 % 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

20

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, complete frustration.

Requirements are inconsistent and/or incomplete.

It is expensive to make changes to requirements after they have been agreed or/and implemented

RedesignRecodingRetesting

Requirements Engineering

Software Requirements

Features

Needs

Solution Domain

Problem Domain

Requirements Engineering

User Needs:A reflection of the business, personal, or operational problem that must be addressed in order to justify consideration, purchase, or use of a new system

Development teams need to understand true needs

User Needs are often vague an ambiguousI need easier way to understand the status of my inventory/libraryI’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 systemManual control of doors during fire emergencyLinux compatibility

Unfortunately, users often state neither features nor their needs but something in between

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

Users transform needs into believed featuresAdvantages: 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 of 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 systemsPrimarily concerned with processing information which is held in some database.

Embedded systemsSystems where software is used as a controller in some broader hardware system

Command and control systemsA 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

Softwarerequirementsengineering

Requirementspartitioning

Architecturaldesign

Systemrequirementsengineering

Sub-systemdevelopment

Systemintegration

Systemvalidation

Requirements Engineering Process

Types of stakeholders

Software engineers responsible for system developmentSoftware Architects, Designers, Testers, etc.System end-users who will use the system after it has been deliveredManagers of system end-users who are responsible for their workThose managers who pay for the development of the systemExternal regulators who check that the system meets its legal requirementsDomain 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 descriptionsInstruction manual for a dishwasherCookery bookQuality manual for software development

RE process - inputs and outputs

Agreedrequirements

Systemspecification

Systemmodels

Requirementsengineering process

Stakeholderneeds

Organisationalstandards

Domaininformation

Regulations

Existingsystems

information

RE process variability

RE processes vary radically from one organisation to another

Factors contributing to this variability includeTechnical maturityDisciplinary involvementOrganisational cultureApplication domain

There is therefore no ‘ideal’ requirements engineering process

RE process activities

Requirements elicitationNeeds and features discovered through consultation with stakeholders

Requirements analysis and negotiationRequirements are analysed and conflicts resolved

Requirements documentationRequirements document are produced (including specifications)

Requirements validationThe requirements document is checked for consistency and completeness

Spiral model of the RE process

Requirements elicitation Requirements analysis andnegotiation

Requirements documentationRequirements validation

Informal statement ofrequirements

Agreedrequirements

Draft requirementsdocument

Requirementsdocument and

validationreport

Decision point:Accept documentor re-enter spiral

START

RE process problems

Lack of stakeholder involvement Business needs not consideredLack of requirements managementLack of defined responsibilities Stakeholder communication problemsPoor quality requirements documents

Process improvement

Process improvement is concerned with modifying processes in order to meet some improvement objectives

Improvement objectivesQuality improvementSchedule reductionResource 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 organisation

Examples of good practice guidelines

Define a standard document structureDefine policies for requirements managementUse checklists for requirements analysisUse scenarios to elicit requirementsSpecify requirementsReuse requirements

Key points

The requirements engineering process is a structured set of activities which lead to the production of a requirements document.Inputs to the requirements engineering process are information about existing systems, stakeholder needs, organisational standards, regulations and domain information.Requirements engineering processes vary radically from

one 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 formal documentused to communicate the requirements to customers, engineers and managers.

The requirements document describes:The services and functions which the system should provideThe constraints under which the system must operateOverall properties of the system i.e. constraints on 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 customersspecify the requirements and read them to check they meet their needs

Project managersUse the requirements document to plan and manage the development process

System engineersUse the requirements to understand the system being developed

System test engineersUse the requirements for testing

System maintenance engineersUse 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

Introduction1.1 Purpose of requirements document1.2 Scope of the product1.3 Definitions of terms1.4 References1.5 Overview of the document

Requirements document structure

2. General description2.1 Product perspective2.2 Product functions2.3 User characteristics2.4 General constraints2.5 Assumptions and dependencies

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

4. AppendicesIndex

Guideline for Requirements Document

Define a standard document structureExplain how to use the documentInclude a summary of each requirementMake the document easy to read/changeHelp readers find information

Writing requirements

Requirements are usually written as paragraphs of natural language text supplemented by diagrams

Problems with requirementsuse of complex conditional clauses which are confusingsloppy and inconsistent terminologywriters 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 of the requirements document

Writing guidelinesDefine 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” SyndromeSoftware are abstract and often cannot be experienced by usersMechanical 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 of application development. We must plan for it.

“Undiscovered ruins” SyndromeThe more you find the more you know remain.Be aware of the point where to stop searching.

Challenges of Requirements Elicitation

“User and Developer” SyndromeCommunication gapUsers 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 of 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 requirementsThis knowledge must be structured

Partitioning - aggregating related knowledgeAbstraction - recognizing generalitiesProjection - organizing according to perspective

Elicitation problemsNot enough time for elicitationInadequate preparation by engineersStakeholders are unconvinced of the need for a new system

Elicitation techniques

InterviewsWorkshopScenariosObservations and social analysisRequirements reuseStoryboarding

Interviews

The requirements engineer or analyst discusses the system with different stakeholders and builds up an understanding of their requirements.Types of interview

Closed interviews. The requirements engineer looks for answers to a pre-defined set of questionsOpen 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 importantForges an agreement between stakeholders and developersExposes and resolves political issues

Requirement Workshop

Sell the concept to your colleagues“Not another meeting”, “You’ll never get XX”,

Target the right stakeholdersHigh degree of professionalism in the logistic preparationSend warm-up materials

Not too early, not too late

Requirement Workshop

Facilitator:

Preferably from outside the organizationExperienced with requirements engineering issuesTeam and consensus building skillsWell respected by other team members

Requirement Workshop

Facilitator Task:

Establish a professional and objective toneStarts and stops the meeting on timeEstablishes and enforce the rulesIntroduces the goals Manages the meeting and keep people on trackControls disruptive or unproductive behaviorMakes sure that all stakeholders participateMakes 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 scenariothe normal flow of events in the scenarioexceptions to the normal flow of eventsinformation about concurrent activitiesa description of the system state at the end of the scenario

Scenarios are examples of interaction sessions of users with the systemDiscovering scenarios reveals

possible system interactions facilities which may be required

Scenarios and OOD

Scenarios are an inherent part of some object-oriented development methodsThe term use-case (i.e. a specific case of system usage) is sometimes used to refer to a scenarioThere are different views on the relationship between use-cases and scenarios:

A use-case is a scenarioA 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 workEthnography is a technique from the social sciences which has proved to be valuable in understanding actual work processesActual work processes often differ from formal, prescribed processesAn ethnographer spends some time observing 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 workingSpend time getting to know the people and establish a trust relationshipKeep 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 systemReuse saves time and effort as reused requirements have already been analyzed and validatedRequirements 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 incurredEssential for developing the ‘look and feel’of a user interfaceCan be used for system testing and the development of documentationForces a detailed study of the requirements which reveals inconsistencies and omissions

Types of prototyping

Throw-away prototypingAims at eliciting the system requirements. The prototyped requirements are those which cause most difficulties to customers and which are the hardest to understand.

Evolutionary prototypingAims 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 toolsDevelopment costs - depend on the type of prototype being developedExtended development schedules -developing a prototype may extend the scheduleIncompleteness - 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

InexpensiveUser friendly, informal, and interactiveEasy to create and modifyPrevent the “blank-page” syndrome

Types of Storyboards

Passive storyboardsTell a story to the userIncludes sketches, pictures, screenshots. The analysts plays the role of the system and walks the user though the storyboard

Active storyboardsPresent a movie of a system that does not exist yetAnimated, automated, animated slides, home made movies, simulations

Interactive storyboardsUser 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 anythingDon’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 requirementsto highlight requirements conflicts andto 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 1For overlapping requirements, fill in a 1000For 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 prioritiesRequirements negotiation is the process of

discussing requirements conflicts andreaching 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

Requirements 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 expensiveStoryboard are technically and cost effectiveChecklists are particularly useful as a way of organizing the requirements validation process.Requirements negotiation is always necessary to resolve requirements conflicts and remove requirements overlaps. Negotiation involves information interchange, discussion and resolution of disagreements.

Assignment IProblem 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 of 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 IQuestions:

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

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

Q & A