1 / 53

Requirements Analysis

Requirements Analysis. Presented by iiba Study gROUP : Julie, Alexis, nicole. Introduction. What is requirements analysis?. Requirements Analysis ( Chapter 6 )

cstamper
Download Presentation

Requirements Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Requirements Analysis Presented by iiba Study gROUP: Julie, Alexis, nicole

  2. Introduction

  3. What is requirements analysis? • Requirements Analysis (Chapter 6) • describes how business analysts prioritize and progressively elaborate stakeholder and solution requirements in order to enable the project team to implement a solution that will meet the needs of the sponsoring organization and stakeholders. • involves analyzing stakeholder needs to define solutions that meet those needs, assessing the current state of the business to identify and recommend improvements, and the verification and validation of the resulting requirements.

  4. Relationships Between Knowledge Areas • Where does Requirements Analysis sit within the knowledge areas?

  5. Scope • In-scope: • What is Requirements Analysis • Where does it fits in the framework • Inputs, Tasks and Outputs: • 6.1 Prioritise Requirements • 6.2 Organise Requirements • 6.3 Specify and Model Requirements • Methods – Voting, MoSCoW, Timeboxing – Budgeting • Addams Family holiday requirements • Quiz

  6. Req. Analysis - Inputs, tasks and outputs

  7. Tasks (In-scope)

  8. The Addams Family - Requirements • Stakeholders: • Mr Addams • Mortisca • Cousin IT • Wednesday • Pugsly • Method: • Hard to contact, used email and group conference calls. • Output: • Summarized results presented – brief report

  9. The Addams Family - Requirements • Requirements: • Wifi • Minimal light • Duration of holiday • Stakeholders: • Mr Addams • Mortisca • Cousin IT • Wednesday • Pugsly

  10. VOTING Voting methods: eMail voting Stickers or marking pen on posters, coloured paper or butchers paper Poker chips / group session Surveys Tally the totals, list highest to lowest Report back to stakeholders Poker chips image: http://www.danielmello.net/creativeworks/shorties/28/06/2013 Paper image: http://www.eckersleys.com.au/products/craft/scrapbooking/scrapping-paper 28/6/2013

  11. Voting VIA EMAIL Why/when to use it? To get agreement with multiple stakeholders, or reduce multiple options When peers need to make a decision When hierarchy doesn’t dictate the top priorities When locations are spread around (optional) Consider weighted voting based on influence Outlook image: http://www.technipages.com/outlook-2010-2007-send-a-vote-email.html 28/9/2013

  12. Voting VIA EMAIL To set up eMail voting: From my Outlook … New message > Options tab > click Use Voting Buttons > click Custom … Outlook image: http://www.technipages.com/outlook-2010-2007-send-a-vote-email.html 28/9/2013

  13. Voting VIA EMAIL eMail voting– Properties dialog Enter whatever options you need in the Use voting buttons free-text field with colons separating the options (;) no spaces Click Close Back at the untitled email, the Use Voting Buttons will now have the new options included – and selected. Outlook 2010 image: JRose28/9/2013

  14. Voting - outputs • In the eMail invitation, the Vote button includes the list of options for people to select between (in this case, Indian, Thai or chinese) • Outlook enables easy tallying once votinghas started (see Tracking tab) • Survey - reports Image: http://www.techrepublic.com/article/techrepublic-tutorial-use-outlooks-built-in-voting-feature-to-create-custom-voting-buttons/1052321 28/06/2013

  15. Method – MoSCoW Analysis • What is MoSoW? Recommended method for setting priorities. • MoSCoWanalysis divides requirements into four categories: • Must: a requirement that must satisfied in the final solution, if not delivered it could result in project failure. • Should: a high-priority item that should be included in the solution if it is possible. • Could: a requirement which is considered desirable but not necessary. Included if time and resources permit. The first to go if the project timeline or budget comes under pressure. • Won’t/Wouldn’t: a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. • Could and would requirements are 'nice to have' and do not affect the overall success of the project. • Benefits: Helps understand the most important requirements.

  16. MoSCoWAnalysis – addams family example • Must– The holiday duration must be for a total of 7 days, within $1Million • Or • Should– The holiday destination should be held in a cold destination. • - The Addams family should have individual activities they can participate in. • Could– The Addams family could visit some weird places. • or • Wish list, want or won’t– The Addams family won’t participate in grave digging activities while on holiday.

  17. Methods – Timeboxing – Budgeting • What is Timeboxing/Budgeting? • A technique to prioritise requirements for investigation and implementation based on allocation of a fixed resource. • It is used when the solution approach has been determine. • All In: Begin with all eligible requirements with assigned Duration or Cost. Remove the requirements in order to meet the calendar dates or budget limits. • All out: Begin with adding the requirement(s) with assigned duration or cost to the calendar or budget. Stop when the calendar dates are met or budget limit is reached. • Selective: Begin by identifying high priority requirements added to the calendar or budget. Add or remove requirements in order to meet the calendar date or budget.

  18. Timeboxing– Budgeting – Addams Family Example • Budget for the whole trip: $10m • Activities: • Cousin’s IT Haircut - $3m • Cold Cave’s tour guide - $4m • Cold Cave tour without guide - $2m • Expected shopping cost - $3m • WiFi cost - $750,000 • Morticia’s ‘dead coffin’ beauty products - $6m

  19. Process Modelling • 9.21.1. To understand how work that involves multiple roles and departments is performed within an organisation. • Initiated by an event in the business domain, such as a sale of a product to a customer, a request for information by a senior executive, or a failure to complete a transaction. • There are a number of frameworks and methodologies that focus on process improvement methods, such as Six Sigma, Lean, and a large number of proprietary BPM approaches.

  20. Process Modelling • 9.21.1. To understand how work that involves multiple roles and departments is performed within an organisation. • Initiated by an event in the business domain, such as a sale of a product to a customer, a request for information by a senior executive, or a failure to complete a transaction. • There are a number of frameworks and methodologies that focus on process improvement methods, such as Six Sigma, Lean, and a large number of proprietary BPM approaches.

  21. Process Modelling • Advantages: • Most stakeholders are comfortable with the basic elements of and concepts behind a process model. • Process models are effective at showing how to handle a large number of scenarios and parallel branches. • Process models are likely to have value in their own right, as they will be used by business stakeholders for training and co-ordination of activities. • Disadvantages: • Process models can become extremely complex and unwieldy if not structured carefully. Complex processes may involve enough activities and roles to make them almost impossible for a single individual to understand. • Problems in a process cannot always be identified by looking at the model. It is usually necessary to engage stakeholders directly to find problems they have encountered.

  22. Process modelling Basic Shapes • Activity • Decision • Subprocess • Process Flow • Start/End • Document • Database/System

  23. Process Modelling

  24. Process modelling • Great way to communicate visually • Showing Addams Family vacation with each person in their own swim lane • Use of colour • KISS principal • Include a legend and any scaleon X and Y axis (eg Names, ay of the week)

  25. scenarios and Use Cases • 9.26.1 Scenarios and use cases are written to describe how an actor interacts with a solution to accomplish one or more of that actor’s goals, or to respond to an event. • Scenarios: • describe just one way that an actor can accomplish a particular goal. • written as a series of steps performed by actors or by the solution that enable an actor to achieve a goal. • Use Cases: • describes several scenarios in the form of primary and alternate flows. The primary or basic flow represents the simplest way to accomplish the goal of the use case. BABOK 9.11 www.uml-diagrams.com

  26. What is a use case? • “User Case” – Definition A “User Case” describes how an actor interacts with a system in order to achieve a goal. • Use Cases vs. Requirements • “Are use cases requirements?” - Yes, they are a specific type of “Functional” Requirement which define what a system is supposed to accomplishe.g. performing calculations etc. • Use Cases vs. User Stories (Agile) • Use Cases describe the “behaviour” to be built into the system to meet users needs. They are requirements. • User Stories describe the “User needs” that is needed to be done by a person in their day-to-day job. They are not requirements. • The Practical Guide to Use Cases (ebook) by Michael Shrivathsan

  27. Elements • What should be used: • Scenarios or use case must have a unique name • Includes a verb to describe the action taken by the actor • Includes a noun describing the target of the action The Practical Guide to Use Cases (ebook) by Michael Shrivathsan

  28. Use Cases • Definition of Common Terms • System – a computer, electronic or mechanical system • External System – system outside the external system • Actor - human person or external system • Goal – why the Actor interacts with the system • Pre-condition – assumptions • Post-condition – true at complete state “successful” or “fail” • Relationships – extend or include

  29. Use cases • Advantages: • clarifying scope and providing a high-level understanding of user behavioural goals • Disadvantages: • The BA might frequently a temptation to use them to capture all requirements • Use cases do not have any features to support integration or the discovery of common elements

  30. Use Cases - Who are they for? • Primary readers are: • Business Analyst • Project/Program Managers • Programmers • QA Testers • Product Managers • Engineering Managers • Review & Approvers of the functionality: • Managers & Executive • Customers • Partners

  31. Use Cases – Why? • Key Benefits: • Can be written using a standard template and process. • Programmers: • Use cases are easier to read and understand • Users, Customers: • Use cases are easier to identify • Approved & Executives: • Use cases help with identifying what needs to be removed, or what is missing

  32. Questions

  33. Quiz • 10 Questions

  34. Question 1 • In prioritizing requirements, your team decided to select requirements that present the highest risk of project failure and implement it first. What is the basis of prioritization used? • A. Business or technical risk • B. Business value • C. Implementation difficulty • D. Likelihood of success

  35. Question 1 - answer • In prioritizing requirements, your team decided to select requirements that present the highest risk of project failure and implement it first. What is the basis of prioritization used? • A. Business or technical risk • B. Business value • C. Implementation difficulty • D. Likelihood of success • Answer: A. BABOK 6.1.4

  36. Question 2 • Which of the following statement best describes the purpose of organizing requirements? • A. To analyze stated requirements in order to define the required capabilities of a potential solution that will fulfil stakeholder needs. • B. To create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives. • C. Describe the structures and types of requirements information that stakeholders expect. • D. To analyze expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models.

  37. Question 2 - answer • Which of the following statement best describes the purpose of organizing requirements? • A. To analyzestated requirements in order to define the required capabilities of a potential solution that will fulfil stakeholder needs • B. To create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives. • C. Describe the structures and types of requirements information that stakeholders expect. • D. To analyze expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models. • Answer: B. BABOK 6.2.1 • A is the purpose of requirement analysis as a whole. • C is an input to the organize requirement task. • D is the purpose of 6.3 Specify & Model Requirements

  38. Question 3 • Analysts should work to identify opportunities to improve the operation of the business. Some common examples of opportunities that a business analyst is likely to identify include all of the follow EXCEPT: • A. Automate Or Simplify The Work People Perform • B. Reduce Complexity Of Interfaces • C. Increase Consistency Of Behavior • Improve Access To Stakeholders

  39. QUESTION 3 - ANSWER • Analysts should work to identify opportunities to improve the operation of the business. Some common examples of opportunities that a business analyst is likely to identify include all of the follow EXCEPT: • A. Automate Or Simplify The Work People Perform • B. Reduce Complexity Of Interfaces • C. Increase Consistency Of Behavior • Improve Access To Stakeholders • Answer: D. BABOK 6.3.4.5

  40. QUESTION 4 • MoSCoW stands for: • M__________ • S___________ • C __________ • W__________

  41. QUESTION 4 - ANSWER • MoSCoW stands for: • M__________ • S___________ • C __________ • W__________ M - Must S - Should C - Could W – Won’t

  42. QUESTION 5 • In a requirement prioritization session, the team has decided to begin with adding the requirements with assigned duration or cost to the calendar and stop when the calendar dates are met or budget limit is reached. What prioritization technique is used? • A. MoSCoW • B. Time boxing/budgeting – All in • C. Time boxing/budgeting – All Out • D. Voting

  43. QUESTION 5 - ANSWER • In a requirement prioritization session, the team has decided to begin with adding the requirements with assigned duration or cost to the calendar and stop when the calendar dates are met or budget limit is reached. What prioritization technique is used? • A. MoSCoW • B. Time boxing/budgeting – All in • C. Time boxing/budgeting – All Out • D. Voting Answer: C. BABOK 6.1.5.3

  44. QUESTION 6 • In a requirement prioritization session, you gave stakeholders play money and asked them to distribute among proposed features and requirements. What prioritization technique are you using? • Texas Hold-em • Decision Analysis • Budget based • Voting

  45. QUESTION 6 - ANSWER • In a requirement prioritization session, you gave stakeholders play money and asked them to distribute among proposed features and requirements. What prioritization technique are you using? • Texas Hold-em • Decision Analysis • Budget based • Voting Answer: D. BABOK 6.1.3.4

  46. QUESTION 7 • Please link the correct cardinality description to its notion in an Entity-Relationship diagram:

  47. QUESTION 7 - ANSWER • Please link the correct cardinality description to its notion in an Entity-Relationship diagram: Only one (A) Any number (Zero to many) (B) Any number from one to many (C) Zero to one (D) Answer: BABOK 9.7.3

  48. QUESTION 8 • What do Terminal Points in process modelling diagrams represent? • A. Terminal points represent the end of a process or process flow. • B. Terminal points represent the beginning of a process or process flow. • C. Terminal points represent the beginning or end of a process or process flow. • D. Terminal points occur outside the scope of a process and may be the result of actions taken, messages received, or the passage of time

  49. QUESTION 8 - ANSWER • 8 What do Terminal Points in process modelling diagrams represent? • A. Terminal points represent the end of a process or process flow. • B. Terminal points represent the beginning of a process or process flow. • C. Terminal points represent the beginning or end of a process or process flow. • D. Terminal points occur outside the scope of a process and may be the result of actions taken, messages received, or the passage of time • Answer: C. BABOK 9.21.3

More Related