Softeng - Software Requirements Feb 2004

Software Engineering Wouter Brissinck 2005

Managing Software Requirements : Ch 1-The Requirements Problem

The Goal of Software Development • Software Quality implements Murphy’s law – Must be perfect for ordinary software – Must be ridiculously perfect when lives are at stake

• On time, within budget • Meet real customer’s needs – Off the shelf – Project-based, tenders, … – Internal

Software Engineering = ? “The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines” Fritz Bauer “The application of a systematic, disciplined, quantifiable approach to development, operation and maintenance of software” IEEE

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

Software Development Process – Every project needs a process • • • • •

Defines responsibilities of team members Defines which activities are performed Defines timing in relation to other activities Defines details and steps in the activities Defines required registrations of the activities, to insure traceability

– Always document the process • Helps new people on the team • Required by quality standards (ISO 9001)

Software Development Procedures • Procedures : – – – – –

Define terms Define responsibilities Define methods Plan/Do/Measure/Act Create registrations

• Adapt the procedures to the project & team

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

The Waterfall Model – Pre-historic : code & fix (2-phase model) – 50-60ies : Waterfall model (requirements -> design -> code -> etc …) • Emphasize need for requirements

– 1970 (Royce) : Improved Waterfall Model • Feedback loops (design affects requirements, …) • Develop Prototype system during requirements and design activities

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

The Waterfall Model

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

The Waterfall Model – Problems • Real projects are not sequential • Creates barriers between phases • Requirements are “frozen” to the lifetime of the project – Independent of market situation or user’s needs

• Doesn’t take scope management into account – No means to react on underestimation of the effort required

• Changes in “closed” process confuse people • Requirements seldom known beforehand • Result obtained very late in the process – Errors can be very costly

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

The Spiral Model – Boehm (1988) • Successively build Product spec – prototype – core version – functional version – enhanced version – etc … • Each version undergoes similar process – Sequence of task regions (waterfall …) – Each region defines task set (adapted to project)

• Allows for several phases of customer feedback, combined with a rigorous sequential process – Better understanding of the system after each iteration

• Reduce risk using prototypes

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

Spiral Model

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

The Spiral Model – Problems • Prototypes give users the feeling it’s “done” • Prototype code is often transferred to production code – Creates instant legacy code

• Usually no time to produce several prototypes …

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

The Iterative Approach – Kruchten (1995) • Decouple lifecycle phases from software development activities – Phases vs. Iterations

• Mitigate whatever risks are present in each stage of development

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

The Iterative Approach – 4 Lifecycle Phases • Inception : – – – – – –

Understand the business case for the project Understand feasibility of implementation Perform problem analysis Create a vision for the solution Define preliminary estimates of schedule and budget Define project risk factors

• Elaboration – Redefine requirements – Define initial architecture – Develop first prototype

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

The Iterative Approach – 4 Lifecycle Phases • Construction – Focus on implementation – Coding – Unit testing

• Transition – Beta Testing – Train users and maintainers – Deploy

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

The Iterative Approach – Iterations • Iteration = sequence of activities with an established plan and evaluation criteria, resulting in a deliverable (release) • Mini-waterfalls, tuned to the phase

– Disciplines • Logically related set of activities • Defines how activities must be sequences to produce a deliverable

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

The Iterative Approach

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

Requirements in the Iterative Approach – Requirement activities are performed throughout the lifecycle • Refine requirements (increase level of detail) during each iteration • Add requirements late in the project

– Scope Management • Early iterations provide input the planning of the next – How difficult are things ? – How fast is the team ? – Should we reduce scope, or can we do more ?

• When requirements are well prioritized, each iteration will provide a useful deliverable to the customer

Managing Software Requirements : Ch 3-Requirements and the Software Lifecycle

Key Points – The team’s development process defines who is doing what, when and how – In the waterfall model, software proceeded through a sequence of steps, and requirements were fixed early – In the spiral model, the first steps were taken to a more risk driven and incremental approach to development – The iterative approach, a hybrid of the waterfall and spiral models, decouples the lifecycle phases from the software activities that take place in each phase – The iterative model is a more robust model and provides for successive refinement of the requirements over time

Software Requirements Wouter Brissinck 2005

Bibliography • Use Cases – Requirements in Context, D.Kulak, Eamonn Guiney, Addison Wesley, 2000, ISBN 0201-65767-8 • Software Requirements – Styles and Techniques, Soren Lauesen, Addison Wesley, 2002, ISBN 0201-74570-4 • Managing Software Requirements, Dean Leffingwell, Don Widrig, Addison-Wesley, ISBN 0-321-12247

Managing Software Requirements : Ch 1-The Requirements Problem

The Numbers • In 1994 in the US : – $250,000,000,000 on 175,000 projects – Average cost : • $2,322,000 for a large company • $1,331,000 for a medium company • $434,000 for a small company

– – – –

31% of the projects failed 52.7% cost 189% of the budget $81,000,000,000 is spent on failed projects $59,000,000,000 is spent too much on successful projects

Managing Software Requirements : Ch 1-The Requirements Problem

The Root Causes of Failure

Managing Software Requirements : Ch 1-The Requirements Problem

The Root Causes of Failure – 1/3rd of the projects report as root causes : • Requirements specs • Managing requirements

– Coding is not the problem

Managing Software Requirements : Ch 1-The Requirements Problem

The Frequency of Requirements Errors

Managing Software Requirements : Ch 1-The Requirements Problem

High Cost of Requirements Errors

Managing Software Requirements : Ch 1-The Requirements Problem

High Cost of Requirements Errors – Potential 200x higher cost in fixing error in maintenance phase vs. requirements phase. – Study : • 74% of requirements-oriented issues find during requirements analysis • 7% leak into design • 4% leak into maintenance

– To fix : respecify, redesign, recode, retest, redeploy, corrective action, scrap, warranties, liabilities, redocument, … – Requirements issues : 25%-40% of the project budget

Managing Software Requirements : Ch 1-The Requirements Problem

The Requirements Problem : Key Points • Goal : quality software, on time and budget, which meet customer’s real needs • Success depends on effective requirements management • Requirements errors are the most common, and the most expensive to fix

Contents • • • •

What is a requirement ? Elicitation The requirement document Techniques for documenting requirements : – Prototypes – Use Cases – Task Descriptions

What is a Requirement ? • Specific feature, function, or principle a system must provide • Scope of a software project Three kinds : • Data : • Functional : e.g. “When the user types a keyword and performs the ‘search the web’ command, a list of web-pages referring to the keyword are displayed”

• Non-functional ( -ilities) : e.g. “The system should react to all user input within one minute”

Tacit Requirements • Tacit requirement = everybody agrees about it, but it cannot be written down ; implied requirement – Most demands are tacit – Requirements only contain what developers cannot guess (+a bit more to make sure)

Don’t expect you can specify it all

Requirements Gathering (elicitation): Challenges AIM of a software project : « Deliver quality software application, on time, within costs, and to user’s expectations » Problem : business changes, requirements too We need requirements management

Managing Software Requirements : Ch 2-Introduction to Requirements Management

What is Requirements Management ? – A systematic approach to eliciting, organizing, and documenting the requirements of a system – Organize = ? • • • •

Store Prioritize Control access to Assign responsibilities (to the requirement’s documentation itself) • Requirement dependencies (what is affected if changed ?) • Traceability (who develops when, which design doc, which code, which test cases, …)

Purpose of requirements • Validation : check that reqs==user needs • Verification : check that product satisfies requirements (e.g. acceptance test) • Tracing ( demands ↔ reqs ↔ program ) • Requirements management • Court cases (tacit reqs !!)

Requirements Gathering • Job of the analyst : – – – – –

Elicit Analyze for consistency Analyze for feasibility Analyze for Completeness Write it down

Requirements Gathering • Who is part of the req. gathering team ? – – – – –

Project managers Developers Expert users (customer !) Subcontractors + consultants, marketing, …

Requirements Gathering Communicating with users … • Improve your relationship with users • Improve visibility of the project • Have respect for user’s time, job content, skills, …

Requirements Gathering Write a requirements document • Redundant ? Complete ? • Detailed, but not too large ? • Readable by the users and the IT people ?

Requirements : Challenges • • • • • • • •

Reduce Risk Focus on Interactions (NOT Technology) Reduce Volume No Redundancy, No Conflicts Useful to User, Designer, Developer, Manager Traceable No Design Useful till the end of the project

Traceability Everybody on the project should be able to tell at each time during the lifetime of the project what requirement he is working on (analist, developer, tester, maintenance developer, …)

The trouble with requirements gathering • They don’t know what an IT system could do for them • They don’t know what they want • They have conflicting demands • They don’t have time • They change their minds • They don’t understand IT • Yes, but ... • They want it all on paper before you start

Problems observed in practice • Data and functional requirements – Usually developers guess right

• Expectations not met – Business goals not understood by developers

• Background and context – Requirements’ purpose not understood by developers

• Quality requirements – Get too little attention in reqs doc.

The basic rule of writing requirements Requirements and design are different things

Signs of bad requirements • Requirements ≠ Design , What ≠ How, Understanding ≠ Solving • Vagueness • Use of IT jargon (instead : User’s Jargon)

Signs of Bad Requirements « The system should provide restricted remote access (via dial-in) to allow downloading of jpg images » « When the user clicks the « select company » button, the system will show the list of company IDs by performing a query through the ODBC connection, or by accessing the cache if this query was performed recently »

Signs of Bad Requirements « The system should provide restricted remote access (via dial-in) to allow downloading of jpg images » « When the user clicks the « select company » button, the system will show the list of company IDs by performing a query through the ODBC connection, or by accessing the cache if this query was performed recently »

Signs of Bad Requirements « The telephone system must provide a voice response menu, going from a general menu to a secondary menu » « All useful parameters should be present in preferences, which are made non-volatile by saving them in a .ini file.

Signs of Bad Requirements « The telephone system must provide a voice response menu, going from a general menu to a secondary menu » « All useful parameters should be present in preferences, which are made non-volatile by saving them in a .ini file.

Requirements ≠ Design : Why ? Neural diagnostics : Requirement : “System must have a mini-keyboard with just a start and a stop button” – why ? • Only operated by left hand – why ? • Both hands at the patient – why ? • Patient must be calmed and reassured

Requirements ≠ Design : Why ? Neural diagnostics : • • •

System must have a mini-keyboard with just a start and a stop button – why ? Only operated by left hand – why ? Both hands at the patient –

•

why ?

Patient must be calmed and reassured

Why not use speech recognition ?? Requirement : “It should be possible to start and stop the system with both hands at the patient”

Requirements ≠ Design : Why ? • • • •

Design excludes a lot of possibilities Requirements are context insensitive Different authors Requirements must be readable by users

Note : design issues may be added after requirements are finalized

Domain vs. Product Order info

Pointcloud

Audiology Software

Order DB Order CAD file

Production Machine

Scanner Ear impression

Hearing aid

Audiologist Patient

Domain vs. Product • Product – Requirements can describe behavior

• Inner domain = product + direct surroundings – Requirements can describe supported activities – Actor : first-level interaction with product

• Outer domain – second-level interaction

The Goal-Design scale • Goal level requirement – e.g. “Device return rate must dimish from 25% to 5%” – Hard to accept for most software suppliers : not their (sole) responsibility, too much risk involved. (but …) – Product is a concept, a strategy, not necessarily a software. Supplier must be a specialist. – Verification ? Validation ?

The Goal-Design scale • Domain level requirement – e.g. “The process must insure that components fit prior to manufacturing” – Outlines domain tasks to be performed, and requires support for this task by the product – Not restrictive to solution used (i.e. can use customised COTS) – Assumes supplier knows the domain – Verification ? Validation ?

The Goal-Design scale • Product level requirement – e.g. “The software allows to automatically place the selected component in the most optimal position, and to manually adjust the position if necessary” – Identifies a feature of the software – Very specific on the product => harder to use COTS – Assumes less domain knowledge – Verification ? Validation ?

The Goal-Design scale • Design level requirement – e.g. “The component has three circular handles that allow rotation around the three axes” – Describes a product interface in detail – Supplier usually better at designing interfaces than customer. COTS is impossible. – Useful if supplier doesn’t know domain at all – Verification, validation ?

Choose which level ? • Depends on supplier – Management consultant – Niche software supplier – General software supplier

• How much responsibility for customer, how much for supplier ?

Choose which level ? • Goal level: – include to improve understanding – include so that the system can be verified against them

• Domain level : – Include as requirements – or included to explain purpose of requirement

• Design-level : – Include as requirements – Include as an example

Requirement document : Contents • • • • • • • • •

Problem Statement Project overview Data requirements Functional requirements (level ?) Quality (non-func.) requirements Business rules Additional deliverables Managerial requirements (or : in contract) Clarification, context, background

Problem statement • What is the purpose of the project/product ? – e.g. : RSM intends to replace the entire manual process of making hearing aid shells, including canal impression, impression detailing, shell design, and shell manufacturing, by a fully digital process

• If it’s hard to write, everything in the project will be hard.

Project overview • Scope : what ? What not ? • Business Goals/Objectives : What must be Achieved ? • Application Overview : Kind of App. ? • User Demography : who will use ? • Constraints : What IT must take into account (Must run on a 386, ...) • Assumptions : What customer will take care of (e.g. training, deployment, ...)

Data requirements • Database contents (not database structure) • I/O formats

Functional requirements • Many styles and formalisms are available • A lot of functions are trivial : listing them is more important than specifying them • Keep data and functional reqs separate • Domain level <-> Product level <-> Design level

Quality requirements • aka non-functional requirements – Performance (speed, accuracy, capacity, …) – Usability (user-friendly, efficient, training, ..) – Maintenance (easy to change, …)

Additional Deliverables • Documentation • Hardware • Services – – – –

installing training maintaining (updates) converting data

Managerial requirements • Often part of the project agreement, not the requirements – – – – –

planning price and payment (fixed, T&M, variable) testing requirements legal responsibilities intellectual property

Requirements document : finally … • Add a “context” – Customer background (company profile) – Rationale of requirements (why important) – Glossary, examples, diagrams, pics, sample products,…

• Organize using a template – part of standard process – e.g. IEEE 830

The trouble with Requirements docs • • • • •

Differences between written requirements and demand Too much work Off topic, wrong assumptions Too big Not adept to change Extremes : • No requirements (risk of solving the wrong problem) • Requirements are an aim on its own (too expensive, useless) • One-person requirements (App will only work for him)

Prototypes • UI-prototype – Early implementation of the UI (without functionality) – Delay until Finished-iteration

• Technical Prototypes – Part of Design/Research – Implement technically hard tasks early – Can be done during requirements gathering to asses feasability and risk.

Use Cases : Why ? • What interests users ? – System = black box – Interactions between user and system are the only importance – Structurered, non-redundant, maintainable document

Use Cases : What ? • Definition : a use case describes sequences of actions a system performs that yield an observable result of value to a particular actor • Design-level requirements • Write detailed description of each user-system interaction • Show overview of interactions and participants in a diagram Use Case

Use Case Name :

Use case Sell Property

Iteration :

Filled

Summary :

System Context : The seller lists the property, a buyer purchases the property, and the agents guides them through the process and offers advice.

Basic Course of Events

1. Seller lists properties to sell 2. System responds by displaying these properties in the property adds, and includes them in the search engines. 3. Buyer selects an agent 4. System informs agent that buyer wants to use his services 5. Buyer reviews properties by entering search criteria 6. System displays properties that match search criteria 7. …

Use Case : Text • No implementation specific language – no pseudo-code (IF, WHILE, …) – no specific people (“manager”, not “Carl S.”) – no specific user interface description (buttons, menus,…) – no IT jargon (TCP/IP, ODBC, …)

A use case is context-free

UML • Unified Modeling Language (standardized by the Object Management Group) • Notation, not a methodology • Extensible through stereotyping • OO oriented • de-facto standard (= good reason to use it too)

Use Case Diagram • … a UML diagram • Describes interaction between – actor and use case – use case and use case

Use Case Diagram Agent

Sell Property

Buyer

Seller

Use Cases : Actors • Use cases show interactions that provide value to actors – Actors can be • users • other systems (Database) • external events (time-out,...)

– Actors initiate all interactions

Associations • Generalizations of actors – Superactor interacts when all subactors interact in the same way – Subactor interacts when different from superactor employee

App. Engineer

Developer

Associations • Stereotype <<extend>> <<extend>>

Enroll foreign student

Enroll student

• Stereotype <> <>

Indicate plane Planar project curve

<>

Planar cut object

Use Case Template • Provides different entries of the use case text • Not standardized, but you should ! • Each entry should be meaningful and unique • Use Case ≈ 1-2 pages of text (speedreadable)

Use Case Template : example entries • Use Case Name • Use Case Iteration : – façade, filled, focused, finished

• Use Case Summary : what does the use case represent, in 1 sentence • Author • Date (for each iteration)

Use Case Template : example entries • Actors • Basic Course of Events : – Steps taken by actors and system (alternatively) to accomplish goal – Focus on most common path (no exceptions, errors, or alternative paths) – If clarifying, include attachments with diagrams of other kinds, calculations, …

• Related Business Rules

Use Case Template : example entries • Alternative paths : – other (less common) paths through the use case – used to avoid IF-THEN clauses, and user confusion

• Exception paths : – Course of action taken if an error occurs

• Extension Points : – where can an extending use case add interactions ?

Use Case Template : example entries • Triggers : when/why will actors enter this use case • Assumptions : what out-of-scope factors must be true if this use case is to function properly • Pre-conditions : what must be true before the interactions can start • Post-conditions : what will be true after use case was completed successfully (common + alternative paths)

Use Case : Increments/Iterations • • • •

Facade = outline the project, split in parts Filled = deepen, write down details Focussed = narrow the scope Finished = complete and fine-tune Iterations ≠ Phases

Steps to build a use case model • Step 1 : Identify the actors – Find everybody/everything that interacts with the system

• Step 2 : Identify the use cases – – – –

Find what the actor uses the system for Find what the actor needs to tell the system Find what the system needs to tell the actor Provide names and descriptions

Steps to build a use case model • Step 3 : Identify Actor-Use Case relationships – Which actor is involved in which use case ? – Draw the UML diagram

• Step 4 : Fill the use cases – Write the basic course of events – Write alternate/exceptional flows

• Step 5 : Refine the use cases – Add pre/post conditions – Add detail

Scenarios • • • •

Instance of a path Provides specific data Follows a specific path or exception Use : – To illustrate use case functioning to the user (validation) – To provide test cases during testing (verification)

Task Descriptions • Structured text describing user tasks • Domain level requirements • Similar to use cases – task = human and computer perform a common goal together – use case = what part is performed by computer ? Task use case Human

Computer

Task Descriptions • Advantages : – Easy validation and verification – Domain level ( no detailed reqs necessary) – Complex systems can be easily described

• Disadvantages – Design is harder

Assignment • Database for keeping track of companywide training – Mission Statement : provide a system to support the logistics involved in, and the accounting of, training of company employees.

Assignment • Some ideas : – Employees can follow trainings. They often forget they were invited or enrolled in a training. – Trainers (=special employees or external companies) organize trainings. They need to report to management who took part. – ISO9000 requires that trainings are budgetted and that some kind of evaluation on the trainers is performed. – Supervisors (“boss” of an employee) want to know what an employee knows (was trained for) and what not.

Assignment • Write a requirements document – using use cases – using task descriptions – using whatever else necessary