Requirements Management Part 1 - Management and Elicitation
6 likes2,106 views
The document discusses requirements engineering and provides details on various aspects of the process. It covers requirements management, which includes stakeholder analysis, managing scope and risks, requirements traceability, and change management. Requirements elicitation techniques are also examined, such as interviews, documentation analysis, questionnaires, and facilitating meetings. Conflict resolution and qualities of good requirements are additionally addressed.
Requirements Management Part 1 - Management and Elicitation
- 1. Requirements Engineering Mohamed Shaaban| Systems Analyst February 2011| mohamed.shaaban@mail.link.net w w w. l i n kd e v. c o m w w w. l i n kd e v. c o m
- 2. Requirements Engineering I. Requirements Management II. Requirements Elicitation III. Requirements Analysis IV. Requirements Communication w w w. l i n kd e v. c o m
- 3. I. Requirements Management • Stakeholders Analysis • Managing Requirements Scope • Managing Requirements Risks • Requirements Traceability • Managing Requirements Change w w w. l i n kd e v. c o m
- 4. Stakeholders Analysis (1/4) • Focus Areas Outside World – The Immediate Business Area you are Affecting e.g Accounting dept. Enterprise – Rest of the Enterprise Dept. – Outside World – e.g. government, clients, suppliers…etc • Levels of Stakeholders – Primary Stakeholders: have direct influence on your product e.g. end user and sponsor – Secondary Stakeholders: are indirectly affected or can influence the decision of primary Stakeholders w w w. l i n kd e v. c o m
- 5. Stakeholders Analysis (2/4) • Essential Categories – The Boss • Signoff, payment “70% of software purchased isn’t used. 90% of those used are used by • Less knowledge, less time small groups although they are – The Users implemented for large organizations” – Donald Gause and Gerald • Task owners Weinberg • Involvement is vital • Give them what they want, not what you think is right – Subject Matter Experts • Have the Know-how • Vendor/Customer side w w w. l i n kd e v. c o m
- 6. Stakeholders Analysis (3/4) • Planning the Team of Stakeholders – Have a profile for each category • Who they are? Their background, goals, concerns? • How busy are they? “Sampling is selecting representative – Decide who participates in the team elements of a population with the goal to reveal useful information and who presents a key stakeholder about the population as a whole” • Sampling – Kendall and Kendall – Convenient, Purposive, Simple, Complex – Decide on the participation plan of the stakeholders • Top down approach – supervisor first • Two people/level – info validation • Keep the channel open for others w w w. l i n kd e v. c o m
- 7. Stakeholders Analysis (4/4) • Tools to Figure out Stakeholders – Watch the work environment – Check the enterprise organization chart – Any info about the organization e.g. its website – Investigate hard data: who provided it and who received it? • Communication Strategies – Executives: presentations, demos, summaries – Developers: system requirements, usecases – End users: prototypes • RACI – Responsible: does the work – Accountable: is the decision maker (only one) – Consulted: must be consulted prior to the work and gives input – Informed: is on a need to know after the work is done w w w. l i n kd e v. c o m
- 8. Managing Requirements Scope • Identifying Scope – User groups and number of users – Modules and functions of the system – Integration requirements – Deployment locations – Security requirements, platforms, browsers – Data migration – Administration requirements – Specific technology requirements – Others: workflows, reports • Scope Creeps – Source – Mitigation w w w. l i n kd e v. c o m
- 9. Managing Requirements Risks • Common Risks – Lack of key stakeholders involvement – Requirements instability – Ambiguous requirements – Insufficient time assigned to requirements elicitation and analysis – Scope creeps • Risk Management Process – Planning: likelihood, impact, intervention difficulty, mitigation strategy (avoidance, transference, mitigation, acceptance) – Monitoring: perform periodic checks – Controlling: effectiveness of action plans and lessons learned w w w. l i n kd e v. c o m
- 10. Requirements Traceability • Types of Traceability – Requirements are traced back to: • Source: who requested the requirement • Rationale: the business goal that the requirement is to satisfy – Requirements are traced forward to: • Design module(s) • Program code • Test case(s) • Preparing for Traceability – Numbering system – Build a Traceability Matrix Requirements/Test Cases Req 1 Req 2 Req 3 Test Case 1 X Test Case 2 X X Test Case 3 X w w w. l i n kd e v. c o m
- 11. Managing Requirements Change • Your role, as an analyst, is to help the PM by: – Validate change with respect to initial scope – Assess impact of change on other requirements – Document the change • Description, source, reason, priority, date • Update relevant documents e.g. Traceability Matrix. Use revision history – Communicate change to all affected stakeholders – Obtain approval on either delivering the change or scoping it out w w w. l i n kd e v. c o m
- 12. II. Requirements Elicitation • Elicitation Techniques • Conflicts Management • Challenges of Requirements Elicitation • Qualities of Good Requirements w w w. l i n kd e v. c o m
- 13. Elicitation Techniques (1/8) • Elicitation Cycle Elicit Organize Analyze Confirm • Observing and Investigating – Hard data could be documents, websites, invoices, pay slips, forms – Hard data explain only the past – Role of the document: who wrote it to who and why it was created/kept – Hard data are useful to figure out data elements – Data can guide you to stakeholders – who has this data w w w. l i n kd e v. c o m
- 14. Elicitation Techniques (2/8) • Interviews – Must be directed with a specific goal in mind, otherwise you’ll loose track and waste time – Interview many people – complete picture – Listen carefully – every project is different – Find out the interviewee goals – Understand yourself – biases, background, mood – Seek opinions and feelings, not only facts – Revisit issues more than once w w w. l i n kd e v. c o m
- 15. Elicitation Techniques (3/8) • Interviews (cont.) – Preparation • Read related material • Establish interview objectives • Prepare the interviewee – Avoid: • Speaking computers – don’t intimidate the interviewee • Helping the interviewee with answers • Leading questions • Double-barreled questions – what do you do and how! • Walking in with a Design in mind w w w. l i n kd e v. c o m
- 16. Elicitation Techniques (4/8) • Interviews (cont.) – Tips for maximum benefit • Explain what you mean by major terms you use • Order the questions by subject • Assess the knowledge level of the interview and act accordingly • Watch out for signs from the users that show that they are not convinced • Don’t fake that you understand if you don’t • Rephrase and summarize back • Document! w w w. l i n kd e v. c o m
- 17. Elicitation Techniques (5/8) • Interviews (cont.) – Closure • Summarize and give the interviewee a feedback of your impression • Best last question: an invitation to the interviewee to state if there is anything he would like you to know and you didn’t touch on • Tell them what will happen next w w w. l i n kd e v. c o m
- 18. Elicitation Techniques (6/8) • Questionnaires – Avoid them! • Not reliable: Q & A are subject to interpretation • People don’t like filling questionnaires • Take long time to plan, analyze, convince people to fill them • Not for the To Be situation: people cannot envision the future on their own – Use them as a last resort when: • Users are geographically dispersed and it’s hard to reach them • You are running a market survey for an off-shelf product • You need to gather information about the existing situation w w w. l i n kd e v. c o m
- 19. Elicitation Techniques (7/8) • Meetings and Facilitation – Typical complaints about meetings: • Too long and boring • Have no purpose and stray from the subject • Painful – Types of meetings • Collect information • Validate and confirm information • Resolve issues • Report findings • Propose solutions • Raise spirits • Increase/decrease number of ideas w w w. l i n kd e v. c o m
- 20. Elicitation Techniques (8/8) • Meetings and Facilitation (cont.) – To make meetings effective: • Set an agenda and basic ground rules: interruptions, time limit, personal attacks • Provide necessary info for attendees beforehand • Determine who should attend • Record, validate, and publish immediately after the meeting • If the project has too many meetings, it may mean that you either have too many people involved or tasks are not well divided so people cannot work without affecting each other w w w. l i n kd e v. c o m
- 21. Conflicts Management (1/3) • Possibilities or disasters • Essential and inessential conflicts – An essential conflict is a conflict that concerns this particular project at this particular time and involves only those people who are present at the moment or who are the actors at this point – Avoid and delay inessential conflicts w w w. l i n kd e v. c o m
- 22. Conflicts Management (2/3) • Types of conflicts – Personality clashes – “you always”, “you never” • Ask if it’s really a here-and-now issue • Don’t take sides – Personality differences • Optimistic/pessimistic • Micromanagement • Looking for reward/avoid punishment • Like to be in control/under control w w w. l i n kd e v. c o m
- 23. Conflicts Management (3/3) • Types of conflicts (cont.) – Intergroup prejudice – Levels prejudice • Recommendations – Be fully present – Don’t pretend things are not happening – Ask about anything puzzling – Use negotiation skills w w w. l i n kd e v. c o m
- 24. Challenges of Requirements Elicitation • Assumptions – The beginning of a project is when the most assumptions are made. Revisit! – The client also assumes you know things – Ask for clarification and exact information – Give complete, accurate information – Everything is the same. And everything is different – Write down assumptions and confirm them – Ensure that nobody makes fun of someone who asks questions to avoid assumptions w w w. l i n kd e v. c o m
- 25. Challenges of Requirements Elicitation – Writing about the implementation instead of the requirements (the how, not the what) – Missing the real “why” of the requirement – Imposing Solutions on the customer. Remember there’s no perfect solution or one right way – The stakeholders' unwillingness to change or help design a new product w w w. l i n kd e v. c o m
- 26. Qualities of Good Requirements (1/2) • Get Specific – I need certain information to make decisions – let’s list them one by one – The system must not produce too many errors – how many errors is an acceptable number? • Prioritize – for resources and time shortages – The value of the requirement to the customer business – The customer satisfaction if the requirement is implemented – The cost and time needed to implement the requirement – Any obligation that mandate the implementation of the requirement, such as legal obligations w w w. l i n kd e v. c o m
- 27. Qualities of Good Requirements (2/2) – Weigh each requirement on a scale from 1 to 3 Requirement Business value Implementation Customer Obligations Total cost/time satisfaction Req 1 1 0 1 1 3 – Must: indispensable functions in the relevant phase of the product – Should Have: important, but the product will not be useless without them – Nice to have: frill functions that the user can do without, but would like to have if they cost nothing • Prioritize every time new requirements are added or when a function is decomposed into sub-functions w w w. l i n kd e v. c o m
- 28. Exercise • Think about your own biases • Think about how you see change • Case study – Stakeholders Analysis – Risk Analysis – Interview: one on one and observers • Requirements Process • RSD Walkthrough w w w. l i n kd e v. c o m
- 29. Questions w w w. l i n kd e v. c o m