Скачать презентацию Management 1 Requirements Management Elicit requirements Скачать презентацию Management 1 Requirements Management Elicit requirements

2d7a7c432f7841bbc8d10e049d55668d.ppt

  • Количество слайдов: 50

Management : 1 Management : 1

Requirements Management Elicit requirements implement traceability Requirements Model requirements Manage evolution validate requirements 2 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 Configuration Management • Change Control • Version Control • Access to different configurations 3

Definitions • Component (artifact) version – component + modifications – Temporal axis – Initial 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 – 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 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 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 Management • • • Escope Changes Risk Traceability Prioritization 8

Requirement Management • Manage Requirements is to ensure all clients requests are being examined 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 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 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 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 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 • Controlling the scope • Crawling Requirements – New functionality – modifications • requirements • bigger scope SAY NO !!! 14

What means to Prioritize? [Wiegers] • Trade off between: – scope – time – 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 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 Prioritization techniques • Formal – QFD • Informal – CAN 100 – Categorize 17

QFD (quality function deployment) • Participants: – Manager – Key figures – developers [Cohen 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 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 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 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 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. 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 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 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 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 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 Identifying risks • Risk Levels – intolerable – Acceptable if reduction is out of question – Acceptable – negotiable 28

Weighing risks • Probability – low – Very low – high – Very high 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 Risk List Risk level Type of Risk probability Risk description 30

Planning • Detecting the sooner the possible from top of the list (level, probability) 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 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 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 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. Goal: establish the procedure for occupied room Behavioral responses: All rooms in a hallway section can be accessed via a Context: 4 th floor of building 32 , motion detector in order, section entered connected hallway user For each room , the chosen light scene can be set by room using the room control panel For each Chosen light Resource: value T 1 Default light scene for this room, room , the default light scene can be set by using the room control panel. scene 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 • Requirements traceability • Definition: – Ability to follow the life of a requirement • Pre e post traceability • Implicit and explicit • Vertical & Horizontal 35

Pre e post traceability 36 Pre e post traceability 36

Pre e post traceability • Pre traceability: – Before adding to the requirements document 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 Uof. D a e c Pre Traceability g b i d problem f j h REQUIREMENTS Req. Doc Version 1 Pops 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 • 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 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 BWD 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 OO Model 41 Example of Explicit FWD Trace OO Model 41

traceability (vertical) Solicitations: Level 1 Requirements: Level 2 Especification: Level 3 Design: Level 4 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 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; 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 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 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 Uof. D TIME 47

Changes Real Desired • New demands • Incomplete requirements • Inconsistent requirements • Fixed 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 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 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