Task: Elicit & Analyze Requirements
Elicit & Analyze Requirements
Disciplines: EDNA Data and Design


The purpose of elicitation is to ensure that a stakeholder’s actual underlying needs are understood, rather than their stated or superficial desires.


RolesPrimary Performer: Additional Performers:

        Main Description

        Eliciting requirements is a key task in business analysis. Because the Requirements serve as the foundation for the solution to the business needs, it is essential that the requirements be complete, clear, correct, and consistent.

        To fully examine and define the requirements, a combination of complementary elicitation techniques is typically used. A number of factors (the business domain, the corporate culture and environment, the skills of the analyst, and the requirements deliverables that will be created) guide which techniques should be used.

        Some of the generally accepted elicitation techniques include: Brainstorming, Document Analysis, Focus Groups, Interface Analysis, Interviews, Observation, Prototyping, Requirements Workshops, and Surveys/Questionnaires. Each of these techniques is further described in guidance materials attached at the bottom of this task.

        Analyzing requirements includes prioritizing and progressively elaborating stakeholder and solution requirements in order to enable the project team to implement a solution that will meet the needs of the sponsoring agency and stakeholders. It involves analyzing stakeholder needs to define solutions that meet  those needs, assessing the current state of the business to identify and recommend improvements, and the verification and validation of the resulting requirements.


        Prepare for Elicitation

        Preparing for elicitation ensures all needed resources are organized and scheduled for conducting the elicitation activity. The scope should be clarified for the selected elicitation technique and any necessary supporting materials should be gathered. All resources should be scheduled; this includes people, facilities, and equipment. Notification of the plan should be given to the appropriate parties.

        For event-based elicitation (brainstorming, focus groups, interviews, observations, prototyping, and requirements workshops), ground rules must be established. Agreement should be reached with the stakeholders as to the form and frequency of feedback during the elicitation process as well as mechanisms for verifying and signing off on the elicited results.

        Conduct Elicitation Activity

        Elicitation activities are conducted to meet with the stakeholder(s) to elicit information regarding their needs. While ecliting the requirements, it is important to guard against scope creep. Tracing requirements back to the business goals/objectives helps to validate whether a requirement should be included. During elicitation, document the requirements attributes, such as requirements source, value and priority. This will aid in managing each requirement throughout its lifecycle. Tracking the elicitation participants and the actual time spent eliciting the requirements provide a basis for future planning.

        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 results. Validate the stated requirements expressed by the stakeholder match the stakeholder's understanding of the problem and the stakeholder’s needs. Some elicitation techniques benefit from reviewing the documented outputs with the stakeholders to ensure that the analysts’ understanding conforms to the actual desires or intentions of the stakeholder. This could be facilitated by conducting interviews or observing someone work.

        Classify the Requirements

        After reviewing all of the requirements gathered, they should be classified according to the following requirement types:


        · Business Rules (BR) – These are typically rules or policies determined by management or external regulations. They could be related to the federal and state laws and regulations that define how we do tasks. Example: The calculation of graduation rate shall be calculated using the four-year adjusted cohort calculation.

        · Design Constraint (DC) – Refers to some limitation on the conditions under which a system is developed, or on the requirements of the system. A design constraint could be on the system's form, fit, function, technology to be used, materials to be incorporated, time taken to develop the system, overall budget, etc. Example: System must not require double entry of data.

        · Use Case (UC) – Usually sounds like the names of business processes. Generally are verb-noun combinations and state the user’s goal for the system. Example: Calculate the Graduation Rate.

        · Functional (F) – Usually tell how the solution will work. Typically, statements of a single action that must be taken for the solution to be successful. They tell what the solution will do. Example: The entering cohort shall be counted on October 1st of each school year.

        · Quality Attributes (QA) – These requirements that specify usability, reliability, supportability, or performance. These types of requirements sound like quality characteristics that the solution should possess. Example: The page should load in less than 2 seconds.

        · Data Definition (DD) – Describes information that a system creates, reads, updates or deletes. They could include the names of things, their attributes and rules. Example: Dates will be formatted MMDDCCYY.

        · Interfaces (I) – Details the items and ways that the system will retrieve and receive information to external systems. Example: System must retrieve a previous student’s work information from the Federal Work Registration.

        · Physical (P) – Indicates a physical location of the solution. Example: The student must be located at the district's office.

        Trace Requirements

        In the requirements document, the source of each requirement should be identified whether it came from the Sponsor, a Senior Administrator, a State or Federal Partner, a Regulation, the Client, or a User. These indications will be used to determine the overall priority of the requirement.

        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.


        • 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.



        • 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.
        Prioritize Requirements

        Requirement prioritization is a decision process used to determine the relative importance of requirements. The importance of requirements may be based on their relative value, risk, difficulty of implementation, or on other criteria. These priorities are used to determine which requirements should be targeted for further analysis and to determine which requirements should be implemented first.

        The priority of a requirement is determined by the other criteria: Requirement type, Source, and Complexity.

        The following formula should be used to calculate the priority of a requirement:

        Requirement Type + (2*Complexity) + Source


        Requirement Type


        Business Rule


        Design Constraint


        Use Case






        Data Definitions












        Senior Administrators


        State/Federal Partners















        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.

        Define Assumptions and Constraints

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

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

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

        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.

        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.

        Key Considerations

        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.

        More Information