Downloaded 86 times
Uploaded byMark Borowski
Business Analyst Requirements Management
The document discusses the importance of requirements management for business analysts and agile development. It addresses common myths about agile not needing formal requirements. Effective requirements definition includes types, abstraction levels, and best practices like traceability. Stories are discussed as a form of agile requirements but often need further elaboration. Requirements still matter in agile and need to be well-structured, organized, and linked to other artifacts to ensure quality and manage changes.
More Related Content
Similar to Business Analyst Requirements Management
Business Analyst Requirements Management
- 1. Requirements Management The Foundationof the Business Analyst’s Practice
- 2. Do Formal Requirementsstill matter? • What does the Agile development world mean to Business Analysts? • Myths concerning “Agile” and requirements management – “Working code is all that is needed” – “All we need are stories?” – “Small self organizing team can manage architecture” – “Small self organizing team can manage non functional requirements” – “Agile processes have built-in governance”
- 3. Requirements matter nowmore then ever! % of Projects that are Successful
- 4. Requirements Maturity =Strong Foundation
- 5. Without Requirements wecan’t prove completion • Requirements are the contract between business customer and development/IT • Requirements are only as good as their management • Requirements management key components: – Requirements definition – Requirements organization and process – Requirements traceability – Requirements change management – Requirement re-use
- 6. Requirements Definition BestPractices - Types • Not all requirements are created equal • Requirements must have types and attributes • “FURPS+” is a good guide – Functionality - What the customer wants! Note that this includes security-related needs. – Usability - How effective is the product from the standpoint of the person who must use it? Is it aesthetically acceptable? Is the documentation accurate and complete? – Reliability - What is the maximum acceptable system downtime? Are failures predictable? Can we demonstrate the accuracy of results? How is the system recovered? – Performance - How fast must it be? What's the maximum response time? What's the throughput? What's the memory consumption? – Supportability - Is it testable, extensible, serviceable, installable, and configurable? Can it be monitored? – + - addresses design constraints, physical systems needs, interfaces, design rules
- 7. Requirements Definition Abstraction •Four example requirements for an insurance claims processing application: – “We must be able to reduce our backlog of claims” – “The system must be able to automatically check claim forms for eligibility issues” – “The system shall determine whether a claimant is already a registered user, based on his/her social security number” – “The system shall support the simultaneous processing of up to 100 claims ” • Requirements have type and abstraction level – Business needs – Features – Functional software requirements – Non-functional software requirements
- 8. What is AgileDevelopment • The Manifesto for Agile Software Development – Individuals and interactions over processes and tools – Working software over comprehensive documentation – Customer collaboration over contract negotiation – Responding to change over following a plan
- 9. SCRUM – AnAgile Development Process
- 10. The SCRUM Roles • The Product Owner represents the stakeholders, ensuring that the team delivers value to the business. The Product Owner writes customer-centric items user stories, prioritizes them, and adds them to the product backlog • The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.) • Scrum Master - Scrum is facilitated by a Scrum Master who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables • Stakeholders are the customers, vendors. They are people who enable the project and for whom the project produces the agreed-upon benefits that justify its production. They are only directly involved in the process during the sprint reviews
- 11. SCRUM - BusinessAnalysts as Product Owners • Product owners are the interface between business and technology implementers. • User Stories are Agile Requirements • (User) Story – A feature that is added to the backlog is commonly referred to as a story and has a specific suggested structure. The structure of a story is: "As a <user type> I want to <do some action> so that <desired result>" This is done so that the development team can identify the user, action and required result in a request and is a simple way of writing requests that anyone can understand – Example: “As a mobile banking customer I want to take a picture of check from smart phone so I can see deposit instantly”
- 12. Are stories enough? •A story - “As a mobile banking customer I want to take picture of check from smart phone so I can see deposit instantly.” • Stories often lead to other requirements that need to be typed and organized – “mobile check deposit” leads to architectural requirements of persistence, storage, image support – “mobile check deposit” leads to non functional requirements such as image throughput bandwidth, response time, security – “mobile check deposit” likely needs function requirements decomposition for imaging components, for image quality analysis, user verification etc.
- 13. Stories Detailed • Storiescan be elaborated using traditional methods! User Story … .. UI mock ups Others Use Cases … .. Architecture Diagrams BPMN
- 14. Requirements Structure inan Agile world Level Requirements Backlog Owner Requirement Types Themes Portfolio 1 Portfolio Manager Business Vision Epics Traceability * Program Manager Architectural Program Requirements 1 Release Manager Features Product Owners Stories Project * Scrum Master Spikes Agile Team Members
- 15. Requirements Organizational Constructs • Hierarchy • Modules • Links User Systems Test Requirements Requirements Requirements • Baselines TREQ1 UREQ1 SREQ1 UREQ2 SREQ2 TREQ2 UREQ3 SREQ3 TREQ3 UREQ4 SREQ4 TREQ4 UREQ5 SREQ5 TREQ5 UREQ6 SREQ6 TREQ6 UREQ7 SREQ7 TREQ7 UREQ8 SREQ8 TREQ8 UREQ9 SREQ9 TREQ9 UREQ10 SREQ10 TREQ10 Version 2.0
- 16. Requirements Definition BestPractices - Traceability • Traceability is a dependency relationship between artifacts. • It is a methodical approach to managing process and relationship between artifacts • Wikipedia: – Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction – Requirements traceability refers to the ability to define, capture and follow the traces left by requirements on other elements of the software development environment and the trace left by those elements on requirements
- 17. Why Traceability isimportant? • Determine the origin of any requirement • Ensure quality – You can verify that the software fulfills all requirements – You can verify that the software does only what was requested • Help with requirement change management • Analyze impact of a change to a requirement. For example, if a feature is modified, traceability enables you to determine: – Which use cases need to be modified – Which supplementary requirements are affected • Auditiblity/Regulatory certification (DO178B, Sarbanes- Oxley…) • “Every line of code should be directly traceable to a requirement, no extraneous code outside of this process should be included in the build” – DO178B
- 18. Simple link vs.Traceability Simple link e.g. hyperlink Traceability • Unbounded, and unstructured • Bounded • Implicit semantics • Explicit well defined semantics • Unidirectional • Bi-directional • Ad-hoc • Often process governed
- 19. Traceability Anti-pattern - Requirementsin MS Word Documents - Tests in Excel - Link by a common ID
- 20. Requirements – StandardModels • Common Model • More detailed requirement model
- 21. Requirements – Sanitize,Clarify and Consolidate • Usage: to collate together requirements (possibly from several sources) into an agreed specification. • Link Type: “Satisifies". • When Appropriate – When there is a need to clarify and standardize terminology. – When there is a need to reconcile conflicting requirements from different sources.
- 22. Requirements – Dependency • Usage: when requirements are dependent on other requirements being satisfied. Structure is • Link Type: "depends on".
- 23. Requirements – TestCase Coverage • Usage: Show that specific tests are to be carried out proving application meets requirement. • Link type: “Qualifies” (or “Verify”)
- 24. Requirements – Architectureas a constraint • Usage: when architecture is predetermined, rather than derived from the requirements. • Link type: “Constrains”
- 25. Traceability – ImpactAnalysis
- 26.
- 27. The Consequences ofChange
- 28. The Consequences ofChange
- 29. Requirements Change ManagementBest Practice • Requirements can be managed like any other form of work item (task) – Managed with a lifecycle – Assigned, reviewed, approved by appropriate roles based stakeholders – Important in high compliance or governed environments (audit history) – A mechanism to document impact analysis exercise
- 30. Requirement Re-use BestPractices • Module can embed Call Center Mobile Application requirements from others Application Requirements Requirements MREQ1 • Requirements can TREQ1 MREQ2 CREQ1 CREQ1 extended or specialized TREQ2 MREQ3 TREQ3 CREQ2 CREQ3 CREQ4 Core TREQ4 MREQ4 Application TREQ5 MREQ5 Requirements TREQ6 CREQ5 CREQ5 CREQ6 CREQ6 CREQ1 CREQ2 CREQ3 CREQ4 CREQ5 CREQ6
- 31. Summary - Applicationsare only as good as their Requirements • Requirements are the contract between business customer and development/IT • Requirements are only as good as their management • Requirements management key components: – Requirements definition – Requirements organization and process – Requirements traceability – Requirements change management – Requirement re-use
- 32. Bibliography • Writing goodrequirements is a lot like writing good code Jim Heumann, IBM, Software Group, 14 Jul 2004 • IIBA BABOK Guide V2.0, 2009 • Six Things Your CIO Needs to Know About Requirements Maturity, IAG Consulting, 2012 • Agile Software Requirements, Dean Leffingwell, 2011 • The Benefits of Well Managed Traceability, Ed Genrty, Innovate 2012
Editor's Notes
- #6 Requirements not defined until coding has started Requirements changing towards the end of development without an impact assessment Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against Requirements Driven Development Requirements not defined until coding has started. Requirements changing towards the end of development without an impact assessment. Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against
- #16 Requirements not defined until coding has started Requirements changing towards the end of development without an impact assessment Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against Requirements Driven Development Requirements not defined until coding has started. Requirements changing towards the end of development without an impact assessment. Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against
- #17 Requirements not defined until coding has started Requirements changing towards the end of development without an impact assessment Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against Requirements Driven Development Requirements not defined until coding has started. Requirements changing towards the end of development without an impact assessment. Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against
- #22 Source Information modules contain information from any relevant sources. Each could contain collected notes from meetings, emails or entire documents. The Stakeholder Requirements module is the module wherein all the information in the source modules is collated. This collation process must include identification and resolution of conflicts, duplications, irrelevance, etc. The intent is that the module contains a well-written, well-structured requirements specification that can be agreed by all the relevant stakeholders.
- #23 For example, there is no point in being able to bill customers if no records are kept of their expenditure. Two requirements at the same level and A depends on B being met.
- #24 Although the pattern refers to 'Test Cases", in practice, the same could apply for any test or qualification information Need to add test points to a device. These points are not needed normally. Access coverers for mechanical
- #25 The major aspects of this information model are as follows: Specification documents are shaded blue, and are related through “satisfies” links. The Architecture is related to the Specification documents through “constrained by” links. In other words, the Architecture is used to hold design constraints from the design philosophy, for example “use polling not interrupts”. This Link Module captures those relationships that demonstrate how a requirement is constrained by an element in the architecture.
- #32 Requirements not defined until coding has started Requirements changing towards the end of development without an impact assessment Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against Requirements Driven Development Requirements not defined until coding has started. Requirements changing towards the end of development without an impact assessment. Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against
- #33 Requirements not defined until coding has started Requirements changing towards the end of development without an impact assessment Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against Requirements Driven Development Requirements not defined until coding has started. Requirements changing towards the end of development without an impact assessment. Difficulty in determining whether or not the released product satisfies the customer needs because the customers needs weren’t specified Time spent coding, writing test cases or documentation to requirements that no longer exist Engineering blamed for “poor quality” when really there is a lack of requirements to build and to test against