|Task: Gather Business Requirements||
|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.
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.
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
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.
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.
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.
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
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%
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
· 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.
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.
· 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
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
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.
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
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.
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.
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.
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
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.
· 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.
§ 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.
None – some form of requirements gathering should be conducted for all projects.