Lecture 10 CS5702. Requirements Engineering. Managing change optimising Value - A bit more about Agile RE. Requirements Engineering.

(1)

Lecture 10

CS5702

Requirements Engineering

12 November 2009 V1 Semester 1 2009/10 Professor Kevin Ryan

Requirements Engineering Overview

1. Introduction (Week 1)

2. Elicitation of requirements (2 & 3) 3. Standards, Templates and Practice (4) 4. Modelling and analysis of requirements (5 & 6) 5. Documentation of requirements (7)

6. Verification, negotiation, agreement and validation of requirements (8 & 9)

7. Management of requirements (10) 8. Review, Revision, Special Topics (11)

Note change

Requirements Management

Managing change – optimising Value

- A bit more about Agile RE

Expect Change • A fact of life for software….

• Software maintenance accounts for 60-70% of the cost (i.e. effort) invested in a piece of software over its lifetime

• ‘Maintenance’ = Corrective, Perfective and Adaptive changes made to software after it has been

delivered.

(2)

LERO© 2009 THE IRISH SOFTWARE ENGINEERING RESEARCH CENTRE 5 Requirements Change • During elicitation • After elicitation • During documentation • After documentation • During verification • After verification • During validation • After validation • etc….

• Users don’t always know what they want… • Even if they did, they do not always know how to

express what they want precisely… • Analysts are not perfect

• People are only human

• WDKWWWUWSI… (We Don’t Know… ) • Requirements change!

Controlling change

• Controlling requirements change is similar to,

but different from, controlling software

change….

– Software change is a managed by a widely used process called software configuration management. (SCM)

– Requirements change is often not managed at all or is managed badly – not widely done.

• SCM must manage

1.Configuration of the product

Configuration

• A configuration is a set of files which constitutes a software Product

• A configuration item is a unit for the purpose of configuration management

– Such as a Component – Usually source code

• Managed on the basis of file attributes, e.g. creation dates, dependencies etc.

(3)

• A Build List specifies a version of a configuration • A good example is the makefile concept in Unix • The make utility automates the compilation and

linking

• The makefile specifies the configuration itself • But does not keep track of changes, i.e. the different

versions.

• A version is a recorded state of a configuration • Sophisticated tools (first was RCS) keep track of all

the versions of a configuration item

– Variants and – Revisions

• Variants are concurrent versions, e.g. for different platforms

• Revisions succeed other versions in time.

Functions of SCM Tools • Usually “Repository based”

• A Database

– to store the code – to store recorded states – to record the file attributes – to control access

• Developers can

– Check out a configuration item – Lock it (usually done by system) – Resubmit with changes

• Objective is : Controlling change.

Sophisticated

Requirements Management Tools

• To control access by multiple users • To manage changes requirements

• To store the attributes of each requirement… • To track the status of each requirement.. • To help support analysis of the impact of

requirements changes… traceability • To facilitate reuse of requirements…

(4)

• Both aim to control change

• Use a database approach

• Attributes such as Status and Priority • Access control

• Both keep track of dependencies

• Requires, excludes, optional. • Can support traceability

• SCM more concerned with variants • Importance of controlling change varies • RM has more emphasis on Traceability

Good practices include:

• Defining a change control process for requirements • Having a change control ‘board’ for requirements • Performing change impact analysis for each

requirements change

• Having a baseline requirements document • Keeping track of attributes such as Status and

Priority.

More on Agile RE - 1 Recent Field Study (Cao & Ramesh 2008) • 16 companies that used Agile methods in RE • Interviewed employees across wide range of

experience and authority level • Diverse set of application domains

More on Agile RE - 2 Results

• Face to Face

– Benefits: customer input direct; less documentation effort – Problems: not always possible; conflicting needs;

• Iterative RE

– Benefits: better customer relationship; clearer reqts; – Problems: estimation difficult; too little doctn.; NFRs ignored

• Extreme Prioritisation

– Benefits: frequent re-prioritising; use business value (only) – Problems: macro concerns ignored (arch.) ; threshing

• Managing Change thro’ Planning

(5)

Results • Prototyping

– Benefits: quick customer validation; less paper

– Problems: prototype inadequate; expectations unrealistic

• Test-Driven Development

– Benefits: trace requirement to code via tests

– Problems: customers unfamiliar; too low level for them

• Review Meetings & Acceptance Tests

– Benefits: re-assure customers & management – Problems: formal verification missing;

Summary

Reference - Cao & Ramesh : Agile Requirements Engineering Practices: An Empirical Study. IEEE Software Jan/Feb 2008

Tutorial :

• What research method was used by Sin, Alsbaugh and Al-Ani (2008) to identify ‘amethodical’ RE? • Explain what the term ‘figuration’ as used by them. • To what extent, in your opinion, do their conclusions

undermine the notion of an RE method? 2008 Exam Q5

Exam