Requirements Management Part 2 - Analysis and Communication
3 likes1,455 views
This document discusses requirements engineering and analysis. It uses the analogy of blind men feeling different parts of an elephant to represent the various perspectives in requirements analysis, including process, system, functions, and reports. It outlines techniques for requirements analysis like activity diagrams, flowcharts, use cases, and the "Method H" template. The document stresses the importance of effective communication of requirements through documentation, reviews, and revision strategies.
Requirements Management Part 2 - Analysis and Communication
- 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. Blind Men and the Elephant w w w. l i n kd e v. c o m
- 3. The blind man who feels a leg says the elephant is like a pillar w w w. l i n kd e v. c o m
- 4. the one who feels the tail says the elephant is like a rope w w w. l i n kd e v. c o m
- 5. the one who feels the trunk says the elephant is like a tree branch w w w. l i n kd e v. c o m
- 6. the one who feels the ear says the elephant is like a hand fan w w w. l i n kd e v. c o m
- 7. the one who feels the belly says the elephant is like a wall w w w. l i n kd e v. c o m
- 8. and the one who feels the tusk says the elephant is like a solid pipe w w w. l i n kd e v. c o m
- 9. The king explained to them: "All of you are right. The reason why every one of you is telling it differently is because each one of you touched the different part of the elephant. So, actually the elephant has all the features you mentioned." w w w. l i n kd e v. c o m
- 10. III. Requirements Analysis • The system is your elephant, and it has multiple views: – Process Analysis – System Analysis – Functions Analysis – Reports Analysis w w w. l i n kd e v. c o m
- 11. Process Analysis • Swimlane Activity Diagrams – Depict the flow of activities – A lane is assigned to each actor – Data is not present – Allows you to pinpoint problems – Can be used to compare existing models with proposed models w w w. l i n kd e v. c o m
- 12. Process Analysis – Swimlane example w w w. l i n kd e v. c o m
- 13. Process Analysis • Flowcharts – Decide on the level of abstraction you want to include – More user friendly – Less focus on actors – Better view of routing decisions w w w. l i n kd e v. c o m
- 14. Process Analysis – Flowcharts example w w w. l i n kd e v. c o m
- 15. System Analysis • System Leveling for Scoping System Name Major Module 1 Major Module 2 Major Module 3 Task 1 Function 1 Task 2 Function 2 Task 3 w w w. l i n kd e v. c o m
- 16. System Analysis • User Stories – Agile concept – Define user roles and goals • As a book buyer, I want to browse books • As a system admin, I want to cancel a transaction – Find out the details of each story • What is the result of the action, from a business perspective? e.g. after payment, do shipping? • What is the result of the action, from a system perspective? e.g. after saving request, notify user? Keep data? – Find the links between stories • Will order cancellation affect payment? Shipping? – A good story is singular, estimable, and testable w w w. l i n kd e v. c o m
- 17. System Analysis • Use Cases – Scenario description: the user interaction with the system – Easier to envision and customer-friendly – Summarized enough to produce test cases – They lack the integration aspect – They say very little of the data – They deal poorly with quality requirements w w w. l i n kd e v. c o m
- 18. System Analysis – Use Cases example Usecase ID UC-CusAcc-1 Description This usecase scenario describes the steps of creating a new customer profile on the system Actors Sales agent Assumptions & None Constraints Pre-Conditions The sales agent has an active user account and logged in to the system Basic Flow 1. The sales agent chooses to create a new customer profile 2. The system displays the New Customer Profile form (see Data Form 1) 3. The sales agent fills in the form fields and submits it 4. The system checks uniqueness of customer data against existing accounts. Please refer to Uniqueness Check for more information 5. For new customers, the system saves their information and requests a unique identifier (UCID) from the CRM system 6. The system displays a message that confirms creation of the profile to the agent. The message includes the UCID Alternative Flows In step #5, in case the CRM system is down, the system (Offline Sales Portal) should generate a UCID for the new profile, as well as enable the agent to enter a UCID manually into the form. The UCID provided by the agent should w .validateddfor uniqueness against the system database w w be l i n k e v . c o m Post Conditions A new customer profile is created to which new sales can be linked Notes Please refer to Figure 3.1
- 19. Functions Analysis • The following attributes generate the requirement – Who: who will do an action, and who will receive it or be affected by it – Why: the real need, the problem that the requirement will solve – What: the business activity. There are 3 “whats”: • What does the user do (as-is) • What does he want (the real problem) • What does he ask for (to-be) – Where: the environment in which the work takes place, and the scope of implementation across geographical areas and branches – When: timing, not only of delivery but also of the inclusion in the process – How: the implementation, how will the problem be solved (design) w w w. l i n kd e v. c o m
- 20. Functions Analysis • Method H Functionality What do you do? Inputs Outputs Business Rules What do you give What do other What rules apply? to other people? people give you? Data What do you need to keep track of? w w w. l i n kd e v. c o m
- 21. Functions Analysis – Method H example: employee monthly payment Functionality •Take out deductions •Take out taxes/loans •Print check •Post to GL Inputs Business Rules Outputs •Hours worked •Check with manager before •Check •Managers approval calculation •Payments record •Don’t calculate if employee is fired Data •Employee records •Deduction tables •Taxes table w w w. l i n kd e v. c o m
- 22. Reports Analysis • Think about the following – Description: why do users need this report? – Distribution method: will the report be printed? Will it be automatically generated and emailed to customers? – Specific output formats: PDF, Excel… etc – Report usage frequency: daily, monthly, yearly? – Filtering of data – Sorting of rows and order of columns – Grouping rules: by department, then employees title? – Formulas: subtotals, grand totals, average… etc w w w. l i n kd e v. c o m
- 23. IV Requirements Communication • Possible Analyst Deliverables – Stakeholders List – Requirements Specifications Document – Change Requests – Prototype • Horizontal: shallow view of the system with no logic • Vertical: deep slice of the system • Throw-away Prototype: in the form of paper and pen • Evolutionary Prototype: like HTML, extended later to produce the actual application – Internal • Requirements Database • Traceability Matrices • Requirements Management Plan w w w. l i n kd e v. c o m
- 24. IV Requirements Communication • Recommended Documentation Practices Keyword Meaning MUST, SHALL Absolute requirement of the specification MUST NOT, SHALL NOT Absolute prohibition of the specification SHOULD, RECOMMENDED Requirement can be ignored if there’s a valid reason, but the implication must be understood and communicated before choosing a different approach SHOULD NOT, NOT A particular item may be acceptable in certain situations, RECOMMENDED but the implication must be understood and communicated before implementing it MAY, OPTIONAL A requirement is optional w w w. l i n kd e v. c o m
- 25. IV Requirements Communication – Naming Consistency: make sure you use the same terminology with one definition – Separate facts from assumptions and goals from requirements – Writing for an audience • Sophisticated vs. Simple, average users – Introductory section • Always write an introduction to orient readers • Include document purpose, audience, and scope • Refer to relevant documents • Introduce the product w w w. l i n kd e v. c o m
- 26. IV Requirements Communication • Types of Revision – Peer Review: Help you see weak points without the pressure of a supervisor judgment – Technical Review • Developers • Quality Control • Quality Assurance – External/Customer Review • Agreement on Requirements and Signoff w w w. l i n kd e v. c o m
- 27. IV Requirements Communication • Revision Strategy – Check the flow of ideas – Validate the accuracy of information – Review pictures: location and caption – Check clarity and consistency – Proofread: check grammar, spelling, and punctuation – Confirm accuracy of the Table of Content, References, and Index w w w. l i n kd e v. c o m
- 28. Thank You w w w. l i n kd e v. c o m