Requirementsdevelopment 120207165817-phpapp02


Published on

Published in: Business, Technology
1 Comment
1 Like
  • This is excellent!

    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Requirementsdevelopment 120207165817-phpapp02

  1. 1. Requirement Excellence Framework™ Requirements Development
  2. 2. Requirements Development 1 Related Rules Scope Statement Functional Requirement Supplemental Requirement Project Stakeholder Feature Impact Process Impact Stakeholder Need User Story Use Case Project Stakeholders are identified during Stakeholder Analysis and used to define stakeholder needs and user stories. Project stakeholders are also used as actors in Use Cases. Process Impacts are identified during Process Analysis and used to define scope statements. Impacts on products and services are identified during Project Scope and are used to create scope statements. Scope Statements are defined in the Project Scope activity and used to elicit needs and specify requirements. Related Rules are identified during Specification and linked to a requirement. Functional Requirements are created during Specification.. Stakeholder Needs are identified during Elicitation through a variety of elicitation techniques such as web forms, interviews, observatio ns and group discussion. User Stories are a special type of need which are created during Elicitation. Supplemental Requirements are created during Specification.. Use Cases are developed by the analyst during Analysis to gain a better understanding of the sequence of events and user involvement. Note that Requirements Development is an iterative and incremental activity. Generally Elicitation, Analysis, Specification, and Validation go on concurrently.
  3. 3. Elicitation is the process of gathering and documenting needs from stakeholders, identifying other requirements sources, and applying techniques specified in the RMP to gather the information and document the needs • Stakeholder Needs • Document Review • User Stories • Use Cases Analysis is the process of analyzing the data gathered during elicitation, resolving conflicts, analyzing business rules, documenting assumptions, constraints, and dependencies, and working with stakeholders to establish initial priorities. • Stakeholder Needs Analysis • Document Review Analysis • Business Rules Analysis Specification is the process of defining functional and supplemental text based requirements and supporting them with various visualization techniques such as process models, UML diagrams, wireframes, white boarding, etc. • Functional requirements • Supplemental requirements • Visualizations Validation is the process of reviewing the requirement specifications and associated visualizations with the stakeholders for quality characteristics such as completeness, correctness, clarity, practicality, value, etc. • Validated requirement bundle Requirements Development 2 Elicitation Analysis Specification Validation Requirements development is the process of studying stakeholder needs to arrive at as set of complete and prioritized requirements that address strategy, people, process, and technology issues related to the project.
  4. 4. Strategy, People, Process, and Technology 3 Strategy People Process Technology • Business Objectives • Project Vision • Project Scope • Project Constraints • Stakeholder Analysis • Process Analysis • Technical Constraints • Organizational Change Needs • Business Process Needs • Related Business Rules • Use Cases • User Stories • Organizational Change and Training Requirements • Business Process Requirements • Functional Requirements • Supplemental Requirements
  5. 5. Elicitation • The optimal method for eliciting needs is for stakeholders to document their own needs in their own words using the Stakeholder Portal™. The Business Analyst can assist the Stakeholders by providing examples and guidance. • The Stakeholder Portal™ may also be used to capture the needs of a group in the event that a workshop or series of workshops is used. • In the event that workshops or interview are used, analysts need to recognize that customers will not be able to express all their needs in a single workshop or interview. • In addition to system needs, business process and organizational change needs should also be captured. Failure to do so will most likely result in suboptimal solution. • Elicitation requires multiple cycles of refinement, clarifications, and adjustment as participants move from high level concepts to specific details perhaps through a series of releases or iterations. • Related documents, notes, or graphics should be gathered and stored as attachments for further reference. These attachments can be linked to needs in the Stakeholder Portal.™ 4
  6. 6. Elicitation Techniques 5 Documentation Review Review relevant documents such as regulations, internal audit reports Stakeholder Portal Stakeholders record their needs directly using the Stakeholder Portal Use Cases Business Analysts create use cases for major activities and review with Stakeholders Workshops Sessions are held to identify and document user needs Observation Business Analysts document needs by observing work performed Interviews Key stakeholders are interviewed to ascertain their needs Stakeholder Analysis Needs are identified when conducting the Stakeholder Analysis Brainstorming Needs are captured in a brainstorming session using a Mind Map. Business Process Analysis Needs are identified when defining the “To Be” business process model
  7. 7. Elicitation Documentation Confidential - Not for External Distribution 6 Stakeholder Needs User Stories Use Cases Needs are documented in words the stakeholder understands using predefined patterns included in the Stakeholder Portal™ • General Capability • Reports and Queries • Compliance • Security and Controls • Performance • Safety • Operating Environment • Documentation • User Interface • Organizational Change • Business Process Changes Needs are documented using a User Story based on the pattern below As a type of user I need to do this activity So that I can achieve this benefit Business Analyst define use cases to document the work of the stakeholder and how he interacts with the system. A use case is a description of steps or actions between a user (or "actor") and a software system which allows the user to perform a meaningful task. The user or actor might be a person or something more abstract, such as an external software system or manual process. Attachments Related meeting notes, documents, graphics, etc. should be gathered and linked to the artifacts above.
  8. 8. Standish Group Research What factors cause projects to become challenged? 1. Lack of User Input 2. Incomplete Requirements & Specifications 3. Changing Requirements & Specifications Why are projects impaired and ultimately cancelled? 1. Incomplete Requirements 2. Lack of User Involvement 3. Lack of Resources 4. Unrealistic Expectations 5. Lack of Executive Support 6. Changing Requirements & Specifications What is needed to achieve project success? 1. User Involvement 2. Executive Management Support 3. Clear Statement of Requirements 4. Proper Planning 5. Realistic Expectations 6. Smaller Project Milestones 7. Competent Staff 8. Ownership 9. Clear Vision & Objectives 10. Hard-Working, Focused Staff 7 Source: Standish Chaos Report The Requirement Excellence Framework fully or partially addresses most of these issues. Good requirements and user participation will have a major impact on the success of projects.
  9. 9. Requirements Elicitation Risks • Insufficient user involvement leads to unacceptable products • Creeping user requirements contribute to overruns and degrade product quality • Ambiguous requirements lead to ill-spent time and rework • Gold-plating by developers and users adds unnecessary features • Minimal specifications lead to missing key requirements • Overlooking the needs of certain user classes leads to dissatisfied customers • Incompletely defined requirements make accurate project planning and tracking impossible 8
  10. 10. Requirements Planning Activities Documenting the Project Vision • Gaining an understanding of the business strategy and why the project is being undertaken Defining Business Objectives • Defining clear measurable business objectives Business Process Analysis • Identifying what business processes will be impacted • Gaining a full understanding of how the business process will work after the project has been implemented • Determining how the new or modified software will support the business process Project Scope Definition Stakeholder Analysis • Identifying the expected Stakeholders and user classes for the product 9
  11. 11. Requirements Development Tasks Elicitation • Eliciting needs from individuals who represent each Stakeholder Analysis • Analyzing the information received from users • Understanding actual user tasks and objectives • Partitioning system-level requirements into major subsystems. • Understanding the relative importance of quality attributes • Negotiating implementation priorities Specification • Translating the collected user needs into written specifications and models • Reviewing the requirements specifications Understanding the relative importance of quality attributes • Negotiating implementation priorities • Reviewing the requirements specifications Validation 10
  12. 12. Requirements Management Activities • Defining the requirements baseline • Reviewing proposed requirements • Incorporating approved requirements changes into the project in a controlled way • Keeping projects plans current with the requirements • Negotiating new commitments based on the estimated impact of changed requirements • Tracing individual requirements to their corresponding designs, source code, and test cases • Tracking requirements status and change activity throughout the project. 11
  13. 13. Stakeholder Needs 12 Project Scope Record • General Capability • Reports and Queries • Compliance • Security and Controls • Performance • Safety • Operating Environment • Documentation • User Interface • Organizational Change • Business Process Changes Stakeholder Needs Patterns Stakeholder Profile • Stakeholder Needs are captured from the point of view of a stakeholder • Stakeholder needs are organized by Project Scope Records • Stakeholder needs are captured using predefined patterns
  14. 14. User Stories • A user story is a short description of customer’s need. User Stories are commonly used in agile software methodologies and frameworks such as Extreme Programming or Scrum as a way of gathering requirements. • Whenever possible, users should write their own stories; otherwise they can be written by business analyst on behalf of the user. • User stories are generally expressed using the template below. 13 “As a <specific user/ /role>” I what <desired feature/issue that needs to be solved>, so that <benefit from implementing the feature>”

+ Test Cases (Acceptance Criteria)
  15. 15. Use Cases What is a use case? • A use case is a description of how users will perform tasks on your System. • A use case includes two main parts: – the steps a user will take to accomplish a particular task on your site – the way the Web site should respond to a user's actions • A use case begins with a user's goal and ends when that goal is fulfilled. What does a use case describe? • A use case describes a sequence of interactions between a user and a system, without specifying the user interface. • Each use case captures: – The actor (who is using the System?) – The interaction (what does the user want to do?) – The goal (what is the user's goal?) 14
  16. 16. User Stories 15 • Independent • Negotiable • Valuable • Estimable • Sized Correctly • Testable User stories should be written using INVEST.
  17. 17. Other Sources of Requirements • Existing Process Improvements – Help Desk trouble tickets – Trainers and consultants – Help desk and support team – Customer suggestions and complaints – Internal Audit Reports • Process Improvement – Process Benchmarking – Six Sigma Studies • Competition – Competitive products – Analyst Reports • Other 16
  18. 18. Analysis Analysis is the process of analyzing the data gathered during elicitation, resolving conflicts, analyzing business rules, documenting assumptions, constraints, and dependencies, and working with stakeholders to establish initial priorities. • Analysis is not a linear process; it is done concurrently with the elicitation. Business analysts continually monitor needs from stakeholders to ensure understanding and to work with stakeholders that have difficulty in expressing their needs. • Based on the business process analysis, business analyst identify and document business rules that will affect the system. 17
  19. 19. Stakeholder Needs Analysis • Stakeholder needs are analyzed by the requirements analyst using the requirements analysis dashboard • The needs are tagged in variety ways depending on organizational requirements. • Tags can be used for – Return on investment – Must Have, Nice to Have – High, Medium and Low Priorities – Architectural category 18
  20. 20. Business Rules Analysis • Business Rules Analysis is the process of determining what business rules apply to the requirements. • The business rules are maintained by rule book in a knowledgebase • Applicable business rules are linked to requirements during analysis and specification 19
  21. 21. Business Process Analysis • Review the “As Is” and “To Be” business analysis and identify actions that need to be done to accomplish the business objectives, achieve the project vision, and deliver the project scope. 20
  22. 22. Specification Specification is the process of defining functional and supplemental text based requirements and supporting them with various visualization techniques such as process models, UML diagrams, wireframes, white boarding, etc. Confidential - Not for External Distribution 21
  23. 23. How Much Detail do You Need? Confidential - Not for External Distribution 22 • Extensive customer Involvement • Developers have considerable domain • Experience • Precedents are available • Package solution will be used • Outsourced development • Team is geographically dispersed • Testing will be based on requirements • Accurate estimates are needed • Requirements traceability is needed Less Detail More Detail • As usual in software development, the answer to this question is, “It depends.” • The central question to consider when deciding how detailed to make the requirements is: Who do you want to have making decisions about requirements details and when? • If you’re willing to defer many of the ultimate decisions about product capabilities and characteristics to the developers, then you don’t need to include as much detail in the requirements documentation. • However, if you want to ensure that you get exactly what you expect, you need more comprehensive specifications. • Don’t expect that even the best written requirements specification can – or should – replace human dialogue.
  24. 24. Requirements vs. Design Confidential - Not for External Distribution 23 Why undertake the project? (business objectives) What the user will be able to do with the product? (Stakeholder Needs, Use Cases, User Stories) What the developer builds? (Functional and Supplemental Requirements) Systems components and how they fit together? (System Architecture, Component Architecture, UI Architecture) Systems components and how they fit together? (Class Diagram, Database Design, User Interface Design) How the components will be implemented? (Algorithms, UI Controls) Decreasing Abstraction
  25. 25. Writing Clear Requirements Write in Active Voice With active voice, the reader doesn’t have to deduce what entity is doing what. It’s easier for readers to understand explicit and precisely stated requirements that are written in active voice. Fewer assumptions are needed to interpret the requirement. Example: • Passive (weak): When the output state changes, it is logged in the event log. • Active (strong): When the output state changes, the system shall record the new state in the event log. Avoid Ambiguity • An ambiguous requirement is one that the reader can interpret in more than one way, or one that different readers can interpret in multiple ways. Don’t Design the System • If we supply too much detail, we start to design the system prematurely. Danger signs include: name of components, materials, software objects/procedures, database fields, Confidential - Not for External Distribution 24
  26. 26. Writing Clear Requirements Avoid Negation • Before: All users with three or more accounts should not be migrated. • After: The system shall migrate only users having fewer than three accounts. • Before: The security module will not allow access by users who do not have a valid userid and password. • After: The security module shall only allow access by users who have a valid userid and password. Watch for Omissions • Before: The system shall display the user’s defined bookmarks in a collapsible hierarchical tree structure. • After: The system shall display the user’s defined bookmarks in a collapsible and expandable hierarchical tree structure. Be Careful of Boundary Values • Before: 1. If the amount of the cash refund is less than $50, the system shall open the cash register drawer. If the amount of the cash refund is more than $50 and the user is not a supervisor, the system shall display a message: “Call a supervisor for this transaction.” • After: 1. If the amount of the cash refund is less than or equal to $50, the system shall open the cash register drawer. If the amount of the cash refund is more than $50 and the user is not a supervisor, the system shall display a message: “Call a supervisor for this transaction.” 25
  27. 27. Writing Clear Requirements Watch synonyms and Near Synonyms • use terms consistently • define terms in a glossary Be Careful of Similar Sounding Words • “Special Day caller tunes (default) will take priority over all configured individual caller settings that a customer has selected. However, if an individual has been assigned a Special Day caller tune for the same date, this will overwrite the Special Day caller tune.” Pronouns • make the antecedents crystal clear Be Careful with Vague Adverbs • Provide a reasonably predictable end-user experience. • Offer significantly better download times. • Optimize upload and download to perform quickly. • Downloading should complete in approximately 15 minutes. • Exposing information appropriately… • Generally incurs a “per unit” cost… • To enable remedial action to be initiated in a timely manner… • …as expediently as possible… • Occasionally (not very frequently) there will be an error condition… • others: easily, ideally, instantaneously, normally, opti onally, periodically, rapidly, typically, usually 26
  28. 28. Writing Clear Requirements i.e. and e.g. • i.e. = “that is”; e.g. = “for example” • “The system shall use single-letter color codes, i.e., R for red, G for green, and B for blue.” • better to use English Do not Use Vague Terms • user- friendly, modern, robust, efficient, ve rsatile, flexible • efficient, flexible, robust, high- performance • seamless, transparent, graceful • improved, state-of-the-art, superior • rapid, easy, simple, intuitive, • minimize, maximize, optimize • few, several, some, many, approximat ely • sufficient, adequate, at least • reasonable, where appropriate, to the extent possible, • if necessary, optionally • etc., including, and/or • as possible 27
  29. 29. Writing Clear Requirements Don’t Express Possibilities • May, might, should, ought, could, perhaps, probably Avoid Wishful Thinking • 100% reliable • Safe • Handle all unexpected failures • Please all users • Run on all platforms • Never fail Don’t Speculate • Usually • Generally • Often • Normally • Typically Avoid Conjunctions – And, or, with, also Don’t ramble • Example- Provided that the designated input signals from the specified devices are received in the correct order where the system is able to differentiate the designators, the output signal shall comply with the required framework of section 3.1.5 to indicate desired input state. 28
  30. 30. Anatomy of a Good Requirement Confidential - Not for External Distribution 29 User Category Who benefits from the requirement The Call Center operator Expected Result Desirable state for the user to reach shall be able to see the customer record Mechanism to Test Mechanism to allow a test to be written against the requirement. within 2 seconds from the time the call is received.
  31. 31. Quality Attributes for Requirements • Requirement Bundles – Complete - nothing is missing; nothing should say “to be determined” – Consistent requirements should not conflict with other requirements • Individual Requirements – Correct - accurately states a customer or external need – Clear - has only one possible meaning – Feasible - can be implemented within known constraints – Modifiable - can be easily changed, with history, when necessary – Necessary - documents something customers really need – Prioritized - ranked as to importance of inclusion in product – Traceable - can be linked to system requirements, and to designs, code, and tests – Verifiable - correct implementation can be determined by testing, inspection, analysis, or demonstration Confidential - Not for External Distribution 30
  32. 32. Prioritization Scale • Prioritization scale is based on Stephen R. Covey, The 7 Habits of Highly Effective People, Simon & Schuster, 1989 31 Urgent Not Urgent Important High Priority Must be included in the next release Medium Priority Must be included but cant wait for later release Not Important Low Value Do not add sufficient value for to include in the project Low Priority Nice to have if you have the budget to include
  33. 33. Requirement Visualization Requirement Visualization Whiteboarding Storyboards UML Models Photos and Videos Business Process Diagrams Illustrated Concept Diagrams Enfocus Requirement Suite integrates with many requirement visualization tools and technologies. With the Suite, output from these tools can be related to requirements and use cases, as well as other artifacts. Requirement Coach provides guidance for integrating these tools. Wireframes 32
  34. 34. Supplemental Requirements • Performance • Archival and Storage • Security and Controls • Usability • Look and Feel • Access Control • Training • Business Process and Workflow • Infrastructure • Documentation • Business Continuity • System Connectivity • Interface Transaction Confidential - Not for External Distribution 33