Task: Gather Business Requirements
Gather Business Requirements
Disciplines: Business Analysis

Purpose

To ensure requirements are properly gathered, documented, analyzed, and validated. Also, elicitation is to ensure that a stakeholder’s actual underlying needs are understood, rather than their stated or superficial desires.

Relationships

RolesPrimary Performer: Additional Performers:
InputsMandatory:
  • None
Optional:
    Outputs

      Main Description

      This task is the act of taking the information from the elicitation activities and transforming them into requirements. A business requirement is a necessary attribute, capability, characteristic or quality of a solution in order for it to have value and utility to a user.

      Steps

      Gather Requirements

      After the elicitation activities are completed it is necessary to review the notes or results so that they can be parsed into individual requirements. There are many types of requirements review the guidance for more explanation of the different types: Guidance – Requirement Types

      Document Requirements

      Documenting the requirements includes recording the information provided by the stakeholders for use in analysis. The raw requirements should be stated in the Requirements Document and put in the proposed status.

      Classify Requirements

      The following information should be completed for each requirement identified:

      · Complexity – review Guidance – Requirement Complexity

      · Functional Area – review Guidance – Classifying Requirements

      · State – the state of the requirement should be changed as it progresses through the requirements stages.

      Review Requirements

      When documenting requirements it is important to review them several times to ensure each requirement is:

      · Specific, Measureable, Achievable, Relevant, and time-based

      · Independent, Reasonable, Valuable, Estimable, Small, Testable



      It is also help to have a peer review the requirements to help identify gaps, inconsistencies, clarity, etc.



      Review the guidance on Guidance: Characterizes of Good Requirements



      You may also choose to have someone from the technical team review the requirements at this stage to ensure that there is enough information to understand what is being asked. This is not the time for them to tell you whether or not it can be done.

      Prioritize Requirements

      MoSCoW Method-All requirements are ranked as one of the following levels

      ·         Must- These are the critical requirements.  Without them the project fails

      ·         Should- These are important but not critical requirements.  The project won’t fail without them but the customer won’t be very happy.

      ·         Could- These requirements are nice to have but not important.  Often these requirements can raise customer satisfaction without adding much cost or time.

      ·         Would like- These are the least critical, lowest payback requirements.  These often comprise the customer’s wish list.

      *Used for Medium to Large Projects

      Model Requirements

      Models are created to analyze the functioning of an agency and provide insight into opportunities for improvement. They also support a number of other objectives, including development and implementation of solutions, facilitating communication among stakeholders, supporting training activities and knowledge management, and ensuring compliance with contract and regulations.

      Models and diagrams present a graphical representation of a process, vision, idea or method. It is a way of looking at things from a distance to see the whole picture. Different models and diagrams show different aspects of a process.

      Some diagrams are listed below that may help when doing a project (required diagrams are marked with an asterisk *). Review the guidance to learn more about each diagram type.

      · *Business Concept Diagram

      · Business Node Connection Diagram

      · Business Process Hierarchy

      · Process Model

      · Context Diagram

      · Use Cases and Use Case Diagrams

      Define Assumptions and Constraints

      %EOL% Assumptions are factors that are believed to be true, but have not been confirmed. Assumptions may%EOL% affect all aspects of the project and pose a certain degree of risk if they do not prove to be true. The business%EOL% analyst identifies and documents assumptions, attempts to confirm the accuracy of the assumptions, and identifies and%EOL% manages risks related to the ability of a solution to meet the business need.%EOL%

      %EOL%

      %EOL% Constraints are defined as restrictions or limitations of possible solutions. The business analyst is%EOL% responsible for documenting any restrictions or limitations to the solution design, construction, testing, validation,%EOL% and deployment. Solution constraints describe aspects of the current state, or planned future state that may not be%EOL% changed. They are not requirements, since they are not implemented in any form by the project team. Constraints are%EOL% provided to the project team to inform them that options they would normally be allowed to consider are not%EOL% available.%EOL%

      %EOL%

      %EOL% Assumptions and constraints are generally documented with associated attributes (e.g. data identified,%EOL% owner, impact, associated risk, and other explanatory information). They are defined and clarified as requirements are%EOL% understood. In many cases, lower-level requirements may be dependent on, and therefore traced back to, the presence of%EOL% an assumption or constraint and so may be affected if the assumption proves false or the constraint is changed.%EOL%

      Verify Requirements

      Verifying requirements ensures that the requirements have been defined correctly and that they are of acceptable quality. Requirements that do not meet quality standards are defective and must be revised. Requirements verification constitutes a final check by the business analyst and key stakeholders to determine that the requirements:

      ·         Are ready for formal review and validation by the customers and users.

      ·         Provide all information needed for further work based on the requirements to be performed.



      The act of process of establishing the truth, accuracy or reality of something. When you verify requirements you establish that what you document is in fact what the customer meant.This critical process allows you to ensure that the requirements are not tainted by any personal bias you might have. You verify requirements by presenting them in a documented form to the person or group who gave them to you and have them sign off that you captured them correctly.

      Validate Requirements

      Requirement validation is an ongoing process to ensure that stakeholder, solution and transition requirements align to the business requirements.

      Assessing what the outcome will be for the stakeholder when their need is satisfied can be helpful when validating requirements. Implementation of the requirements as a whole must be sufficient to achieve that desired future state for customers and users. In many cases, stakeholders will have different, conflicting needs and expectations that may be exposed through the validation process and will need to be reconciled.

      The act or process of corroborating on a sound or authoritative basis. When you validate requirements you establish that your SME is correct in their understanding of the process.

      By validating requirements you ensure that the SME’s personal bias is not overriding the process. To validate requirements you present them in a documented form to the project sponsor or process owner.

      Baseline Requirements

      ·         Once the requirements are validated the final step is to baseline them. The Functional Specifications Document and Requirements Traceability Document should be completed and then reviewed by the Stakeholders. The Sign Off section of the Functional Specifications Document should be completed with the appropriate signatures. Once the document has been signed off on any changes to the requirements will go through the change management process.

      Document Elicitation Results

      Documenting the elicitation results includes recording the information provided by the stakeholders for use in analysis. A summary of the output from the elicitation activity should be produced to include issues.

      The raw requirements should be stated in the Requirements Document and put in the proposed status.


      Additional documentation can take a number of forms including:

      • Written documents describing the outcomes, such as meeting minutes.
      • Visual or audio recordings.
      • Whiteboards (either actual or virtual) where notes are retained until they are transferred to another medium.

      The technique used for elicitation, as well as the business analysis approach, will determine what kind of documentation is possible and desirable.

      Confirm Elicitation Results
      Confirm the elicitation%EOL%results. Validate the stated requirements expressed by the stakeholder match the stakeholder%sq%s understanding of the problem%EOL%and the stakeholder’s needs. Some elicitation techniques benefit from reviewing the documented outputs with the%EOL%stakeholders to ensure that the analysts’ understanding conforms to the actual desires or intentions of the stakeholder.%EOL%This could be facilitated by conducting interviews or observing someone work.
      Trace Requirements

      The purpose of tracing requirements I to ensure that requirements and designs at different levels are aligned to one another, and to manage the effects of change to one level on related requirements. Traceability identifies and documents the lineage of each requirement including its backward traceability, its forward traceability and its relationship to other requirements.



      Traceability enables faster and similar impact analysts, more reliable discovery of inconsistencies and gaps in requirements, deeper insight into the scope and complexity of change and reliable assessment of which requirements have been addressed and those that have not.



      Review the Traceability Guide for how to tracer requirements in Top Team - Guidance: Top Team Guides

      Determine Complexity

      Each requirement will need to be analyzed to determine the level of complexity. The following scale can be used. All of the conditions for a complexity level do not have to be true in order for the requirement to be considered at that complexity level. If a majority of the conditions exist then the requirement should be classified as such. For example, if the coding, training, and equipment conditions are true under the Low complexity rating but there are no testing scenarios already created as specified under the Medium complexity rating, the requirement would be scored a Low because a majority of the conditions under low were met.

      Low:

      • Coding is perceived to be straightforward with little or no modification to the existing software.
      • Existing testers and scenarios can be utilized to perform the testing.
      • No additional training will be needed.
      • No equipment upgrade needed to support the requirement.

       

      Medium:

      • Coding is perceived to involve some specialized skills, but internal resources are available.
      • Existing testing resources can be used for the testing, but scenarios do not exist.
      • Training in the form of email or memo can be used.
      • Upgrades to hardware or software versions are required, but no new equipment is needed.

       

      High:

      • Coding is perceived to be specialized or hiring of an external source to accomplish.
      • Outside resources will need to be acquired to perform the testing.
      • Classroom-type training will be required.
      • Replacement of existing equipment or supporting software is needed.
      Organize Requirements

      The purpose of organizing requirements is 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.

      There are two key objectives when organizing requirements.

      ·         Understand which models are appropriate for the business domain and solution scope.

      ·         Identify model interrelationships and dependencies. Requirements alone are not complex; it is the relationship and interdependencies among requirements that add the element of complexity. Therefore, the organized requirements must also clearly depict the inherent relationships between requirements.

      Specify and Model Requirements
      Specifications and models are created to analyze the functioning of an agency and provide insight into opportunities for improvement. They also support a number of other objectives, including development and implementation of solutions, facilitating communication among stakeholders, supporting training activities and knowledge management, and ensuring compliance with contract and regulations.
      Hand Off

      ·         After the requirements are signed off on by the appropriate people they should be handed off to the technical team (Technical Analyst, Developer, Testing Specialist, etc.) for review and the next task in the Software Development Lifecycle.  The hand-off can occur in a meeting to review the documentation to ensure there are no questions or clarifications that need to be made.

      Illustrations

      Key Considerations

      §  If a stakeholder group is left out of the requirements gathering process, this could mean some of the requirements are missed.

      §  Not all projects will need to follow all steps, evaluate your project to determine what steps need to be completed.

      §  Sometimes the process of gathering requirements may need to be conducted several times, in order to gather all aspects of the requirements.

      §  The base lining step should not be the first time the stakeholders are seeing the requirements; this should be an iterative process constantly reviewing and revising until all parties are comfortable with the state of the requirements.

      Eliciting requirements is not an isolated or compartmentalized activity. Typically, requirements are identified throughout the elicitation, analysis, verification and validation tasks. Requirements may be elicited in interviews or requirements workshops and later, when those requirements are used to build and verify models gaps in the requirements, may be discovered. This will then require eliciting details of those newly identified requirements.

      Alternatives

      None – some form of requirements gathering should be conducted for all projects.