Requirements Engineering Overview Lecture 10 CS5702 Requirements Engineering Semester 1 2009/10 Professor Kevin Ryan 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 12 November 2009 V1 1 2 Expect Change Requirements Management Managing change optimising Value - A bit more about Agile RE 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. All successful software must change. 3 4 1
During elicitation After elicitation During documentation After documentation During verification After verification During validation After validation etc. Requirements Change Reasons for Change 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! 5 6 Controlling change Configuration 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 2.Changes to that 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. 7 8 2
Versions 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. Changes 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. 9 10 Functions of SCM Tools Sophisticated Requirements Management 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. 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 11 12 3
SCM v RM 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 The process of managing requirements 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. 13 14 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 Benefits: avoids large changes; Problems: where major changes needed can be costly 15 16 4
More on Agile RE - 3 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; More on Agile RE - 4 Summary Reference - Cao & Ramesh : Agile Requirements Engineering Practices: An Empirical Study. IEEE Software Jan/Feb 2008 17 18 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? Exam 2008 Exam Q5 Currently scheduled for 09.00 on Weds 9 th December 19 20 5