Management 1 Requirements Management Elicit requirements implement traceability
Management : 1
Requirements Management Elicit requirements implement traceability Requirements Model requirements Manage evolution validate requirements 2
Configuration Management • Change Control • Version Control • Access to different configurations 3
Definitions • Component (artifact) version – component + modifications – Temporal axis – Initial component (1 a. Version) • Software Version (release) – Set of components taken at a specific point in time • Configuration – Selection of components that are part of a determined set (Ex: components of release 3. 1) 4
Configuration Management • Advantages – Avoid potentially destructive or frivol changes on requirements – Keep/maintain updated revisions of requirements documentation – Facilitate the recovery and reconstruction of previous versions – Offer support to a configuration strategy for new versions – Prevent simultaneous changes 5
Version Control • Coordinate and manage objects in evolution • Successive Refinements – requirements – models – code • Keep intermediary versions • Log of changes 6
rsi on Example Ve Configuration V Configuration IV Configuration III Configuration I Where C – Scenario V - Version 7
Management • • • Escope Changes Risk Traceability Prioritization 8
Requirement Management • Manage Requirements is to ensure all clients requests are being examined during the SDLC • For this, it is essential that such requests are related to software products (requirements allocation) 9
Requirement Management • It is orthogonal to the process of requirements definition (elicitation, modelling and analysis) • Supervene the whole process of software development and evolution 10
What is Scope? • Combination of functionality, resources and time RESOURCES ESCOPE Time Due Date 11
Scope • Problems: – NFR: May consume a big portion of time and resources – Not all resources are available or are known at the beginning – Typical culture that software is always LATE – (time) – save time is an illusion !!! • “Add people to a late project will only get this project worst” Brooks 12
Controlling the scope • “Since” Syndrome – keep adding requirements • Caper Jones reports that requirements that “crawl under the scope” represent – risk of 80% to information system projects – risk of 70% to military projects 13
Controlling the scope • Crawling Requirements – New functionality – modifications • requirements • bigger scope SAY NO !!! 14
What means to Prioritize? [Wiegers] • Trade off between: – scope – time – resources • Assure that the Essential is done 15
Why prioritize? • High Expectations • Short Time • Limited Resources • Saying: “We do what we can not what we want” 16
Prioritization techniques • Formal – QFD • Informal – CAN 100 – Categorize 17
QFD (quality function deployment) • Participants: – Manager – Key figures – developers [Cohen 95/Wiegers] 18
QFD • Steps of the process: 1. List in a spreadsheet the requirements, functionality or use cases that you want to prioritize 2. Estimate the relative benefit of each one using a 1 -9 scale, where 1 means a neglect able one and 9 a grate value requirement 19
QFD 3. Estimate the penalty the client or the business will suffer if the requirements is not included. 1 means a minimum penalty while 9 means a huge loss 4. Create a column - total value – which represents the sum of the benefit and penalty 5. Use a spreadsheet to calculate the percentage of the total value that each item represents (value%) 20
QFD 6. Estimate the implementation cost for each item also using a 1(low) to 9 (High) scale 7. Use the spreadsheet to calculate the percentage of the total cost each item represents (cost%) 8. Estimate the risk each item represents using a 1 to 9 scale 9. Use the spreadsheet to calculate the percentage of the total risk that each item represents (risk%) 21
QFD • Once we have all the estimative: Priority = value%_____ (cost%*cost)+(risk%*risk) • Organize the item using a descending order in priority 22
QFD Critics: • Semi-quantitative method • Not very precise • Depends on personal skills. How well one can estimate benefits, cost and risk 23
Informal Techniques [Leffingwell] $ 100 – Carried out during a meeting – Each participant is given $ 100 to spend buying requirements – Write in a piece of paper how much money you would spend in each requirement – Tabulate results – Requirements ranking 24
Informal Techniques Categorization – off line – Each interested part gets a list of requirements – Classify according to the following criteria • Critical – indispensable • Important – represents loss of functionality or loss off market share • Useful – makes life easier – Set values 1, 2 or 3 (where 1 is critical) – Make a ranking with the results 25
Risk Management • Occurrences that may impact the project • Combination of probability and type of consequence • processes: – identification – Weighing – planning – control 26
Identifying Risks • Conditions, activities, decisions that may affect the success of the project • Types of risk – scope (larger/smaller) – evolution – resources – Personal (outsourced, partners, employees) – New technologies – NFR (very tight (rigid) constraints) 27
Identifying risks • Risk Levels – intolerable – Acceptable if reduction is out of question – Acceptable – negotiable 28
Weighing risks • Probability – low – Very low – high – Very high • Risk list sorted by probability • Risk list sorted by level of risk, type and probability 29
Risk List Risk level Type of Risk probability Risk description 30
Planning • Detecting the sooner the possible from top of the list (level, probability) • alternatives for correction • alternatives to live with 31
Control • Verification points between the global plan and the risk list • Responsibilities • Action (following alternatives) 32
Link Requirements to software components • Also called Traceability, because it must allow one to browse through software products, including the requirements, regarding clients demands. 33
Example: User occupies room - Version 1 Lel entry: Room / Rooms Notion: Part of a hallway section. A room can be a computer lab , an office , a hardware lab , a meeting room, and or a peripheral room. Behavioral responses: Goal: establish the procedure for occupied room All rooms in a hallway section can be accessed via a Context: 4 th floor of building 32 , motion detector in order, user connected hallway sectionentered For each room , the chosen light scene can be set by room using the room control panel For each room , the default scene can be set by Resource: value T 1 Default light scene for this room, Chosen lightscene using the room control panel. value For each room , the value of T 1 can be set by using the room control panel. Actors: user, Control system Episodes: 1. user enters room 2. user chooses light scene 3. IF room is reoccupied wihtin T 1 minutes THEN activate last Chosen light scene 4. IF room is reoccupied after T 1 minutes THEN activate Default light scene 34
Requirements traceability • Definition: – Ability to follow the life of a requirement • Pre and post traceability • Implicit and explicit • Vertical & Horizontal 35
Pre e post traceability 36
Pre e post traceability • Pre-traceability: – Before adding to the requirements document • Where it comes from? • Who suggested? • Why? • Post-traceability: – After something is added to the requirements document 37
Uof. D a e c Pre Traceability g b i d problem f j h REQUIREMENTS Req. Doc Version 1 Post traceability definition Req. Doc. Version 2 Req. Doc Version 3 Req. Document design software implementation maintenance 38
• Explicit Implicit and explicit – Shows the relationship among artifacts – Develop/create relationships from external considerations given by team members – implemented (link or explicit indicator) – The relationship among artifacts is manually done by whom is interested • See next 2 slides for example • Implicit – Inherent to the nature of the artifacts – Examples : A Use Case points to a Sequence Diagram, DFD Process 1. 1 is linked to process 1. 0 39
Actor who was the source of the Knowledge Facility Manager S Safety [Room] Topic has to be a symbol of the LEL Safety [Room. Light scene. Current light scene >= Safe Illumination] Safety [Malfunction of OLS ] Safety [Light Scene. Safe Illumination=14 Lux] S Operationalization Pre-Traceability S S Safety [Malfunction of OLS. All CLG set on] Safety [Room. Malfunction] S S Safety [Malfunction. Motion Detector] Safety [Malfunction. User. Get informed] S S Safety [Room. Control Panel] Safety [Malfunction. FM Get informed] S Safety [Located Near the Door] S = Satisficed P = Partially D = Denied Operationalization 40
Example of Explicit FWD Trace/Post Trace OO Model 41
traceability (vertical) Solicitations: Level 1 Requirements: Level 2 Especification: Level 3 Design: Level 4 42
Horizontal Traceability • Relationship between artifacts of the same type • For example: Req #5 impacts Req #32 43
Why trace? ? ? • Changes in requirements during the development process are natural; • motives: requirements not identified before; changes in the context; errors fixing; new perspectives from the stakeholders; • Changes in requirements may implicate changes in design, code, use case tests etc. Managing Changes 44
Why Trace? ? ? • Aspects related to quality: CMM, CMMI, ISO 9001, SPICE • CMMI: continued modes in levels (staged): staged is similar to CMM, but includes KPAs (Key Process Areas) as well as some changes • KPAs level 2 in CMM are strongly related to ISO 9001 Quality Assurance 45
Changes • The world is always changing – independent – unexpected • Lack of planning • unpredictable • The requirements process implies in changes – All interested parts get to know the Uof. D better 46
Changes Uof. D TIME 47
Changes Real Desired • New demands • Incomplete requirements • Inconsistent requirements • Fixed requirements • Complete Requirements • Consistent Requirements • Clients speaking the same language 48
Evolution Be Prepared for changing !!! • Incomplete, inconsistent Requirements – Latency – Decision • Late binding • Early binding • Unexpected requirements • Non-planned requirements 49
References • [Karsenty 96] – Karsenty, L. – An Empirical Evaluation of Design Rationale Documents - Proceedings of the Conference on Human Factors in Computing Systems – CHI’ 96 – Vancouver, Canada, 1996. pp 150 – 156. • [Jirotka 95] – Jirotka, M. et al. – Ethnography by Video for Requirements Capture – mini tutorial presented at the in the Second IEEE International Symposium on Requirements Engineering (RE’ 95) – York, March 27 to 29 1995. [Carroll 94] – Carroll, J. ; Alpert, S. ; Karat, J. ; Van Deusen, M. ; Rosson, M. – Raison d’etre: capturing design history and rationale in multimedia narratives. Proceedings of Human Factors in Computing Systems (CHI 94) – ACM Press - Boston, USA, 1994. pp. 192 -197 • • [Conklin 96] – Conklin, J. ; Burgess-Yakemovic, KC – A process-oriented approach to design rationale - in Design Rationale: Concepts, Techniques and Use, edited by T. Moran and J. Carroll, Lawrence Erlbaum Associates, Publishers – 1996. pp. 393 -428. [Wood 94] - Wood, D. P. , Christel, M. G. and Stevens, S. M. , A Multimedia Approach to Requirements Capture and Modeling, in Proceedings of the First International Conference on Requirements Engineering IEEE Computer Society Press – Colorado Springs, April 18 to 22 - 1994, pp. 53 -58. [Gotel 95] – Gotel, O. and Finkelstein, A. – Contribution Structures – in the Proceedings of the Second IEEE International Symposium on Requirements Engineering (RE’ 95) – York, March 27 to 29 – IEEE Computer Society Press, 1995, pp. 100 -107. 50
- Slides: 50