Task: Gather Business Requirements
Gather Business Requirements
Disciplines: EDNA Data and Design

Purpose

To ensure requirements are properly gathered, documented, analyzed, and validated.

Relationships

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

      Steps

      Identify Stakeholders

      ·         Identifying stakeholders ensures that all partners, teams, customers, and stakeholder that may be affected by the outcome of the project has input to the ultimate outcome. Identifying stakeholders can be accomplished by reviewing any documentation that has been created thus far in the project and also simply asking the Project Sponsor. Think about the following questions when identifying the stakeholders:

      o   What organizational units/division will be affected by the project?

      o   What roles/positions/teams within and outside the agency will be affected by the project?

      o   Who is the ultimate end user of the system?

      o   Are there any Partners that will be affected by the project?

      The Stakeholder section of the Functional Specifications Document should be completed with the information gathered in this step. Review the Stakeholder Analysis guidance for more information on how to complete the Stakeholder information.

      Determine the current state

      ·         Part of understanding where the agency wants to go is having an understanding of where they currently are. This involves doing some research on the current state of a system, process, vocabulary, etc. The common requirements gathering methods can also be used to gather the current state information. NOTE: While it is important to understand the current state, this step should not consume the majority of the time it should be done to provide an overview or how the current process is handled.  Below is a list of questions to think about when determining the current state:

      o   What current documents or reports are generated?

      o   What current systems, applications and screens are being used?

      o   What current data elements are collected?

      o   What current programs/divisions are involved?

      o   What current processes are there in place?

      o   Are there current buildings, offices or geographical locations that are involved?

      o   What current roles/positions/team is involved?

      o   What customer and partners are involved currently?

      o   Are there certain time profiles that are currently being used?

      o   What software is currently being used?

      o   What functionality is currently present?

      Conduct Research

      ·         Researching best practices is designed to help learn from the experiences of others. There are multiple methods to use to in researching such as; researching other peer organizations, reviewing online discussion groups, using basic internet searches, checking with professional organizations that conduct research, etc. Review the Conducting Research guidance for more information. This step may need to be completed several times throughout the requirements gathering process as new information is gathered.

      Determine Requirements Gathering Method(s)

      ·         There are several different methods for gathering requirements. It is usually best to choose at least two different gathering techniques so that you can ensure requirements are gathered to their completeness. Review the Requirements Gathering Methods guidance to determine the appropriate method for your stakeholders.

      Gather Requirements

      ·         Once you identify who requirements need to be gathered from, and the method that will be used you will need to actually gather the requirements. Review the additional guidance on methods to gather requirements, and types of requirements.

      Classify Requirements

      ·         For each requirement you should classify them according to the status, type, source, and complexity. This can be completed in the Requirements Traceability Document. Review the Classifying Requirements guidance for definitions of the different classifications and their definitions.

      Prioritize Requirements
      Each requirement will need to be prioritized so that they can be implemented in order of importance. If using the Requirements Traceability Document the priority is automatically calculated. If you are not using the Requirements Traceability Document, review the Classify Requirements guidance to calculate the priority.
      Validate Requirements

      ·         Validation of the requirements verifies that they have been captured correctly and accurately reflect the needs of the business. Depending on the type of requirement can determine how it could be validated.

      o   Business Rules can be validated by directly linking them to policies or regulations.

      o   Processes/Use Cases can be validated by verification from one or more SME’s who uses the process described.

      o   Technical requirements and external interfaces could be validated by using current standard procedures.

      o   Data Definitions need to be validated by both the business unit and the technical staff to verify that they agree on the specific definitions.

      o   Functional requirements, general requirements, and quality attributes should be validated with the project sponsor and administration of the business unit.

      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.

      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.

      Alternatives

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