Requirements Definition

Please click on the Inline image 1 to enlarge the full diagram.
requirement definition
Define Functional Requirements Define Non-Functional Requirements Conduct Existing Solution Inventory and Gap Analysis Specify Requirements Obtain Sign-Off of Requirements
  1. Define Functional Requirements
  2. Define Non-Functional Requirements 
  3. Conduct Existing Solution Inventory and Gap Analysis
  4. Specify Requirements
  5. Obtain Sign-Off of Requirements

1. Define Functional Requirements

Requirements Definition is an art and a science. It requires analysts to work very closely with customers and to draw on their communication and technical skills to surface underlying business needs that might be addressed by a system solution. One of the major pitfalls is to “leap to a solution” with an inadequate understanding of the operating problems and fundamental needs of the customer. Requirements analysis is also by nature an explorative and iterative process. Frequently, customers cannot adequately state what they really need until they see what they have asked for in previous requirements iterations with an IT team. As stated earlier in the introduction to this handbook, an iterative project approach may need to be used in which repeated sequences of Requirements Definition, System Design and System Build phases will progressively define and build the solution in iterative or spiral approach.

When developing a project specific work plan, it should be noted that the Work Breakdown Structure for this phase does not necessarily reflect the sequence of how the stages and activities should be performed on a given project. Due to the iterative and exploratory nature of the Requirements Definition Phase it is recommended that stages 1-4 (Define Functional Requirements, Define Non-Functional Requirements, and Conduct Existing Solution Inventory and Gap Analysis) be overlapped and executed concurrently with a finish-to-finish dependency on the publication of the Requirements Specification.

Solution Requirements may be divided into “Functional” and “Non-Functional” requirements. Functional requirements specify what the solution must do. Non-Functional requirement refers to additional Technical and Operational and Performance requirements for the solution to be implemented and supported, but do not by themselves characterize the underlying business problem or opportunity to be solved. In order to clearly understand the customer’s problem domain before devising a solution, functional requirements are defined in a way that makes them independent of a particular technology implementation. They describe the capabilities and functionality of the required solution, not specific software features. For example, a Functional requirement might be: “The system shall accept a student registration for a class” or “The system shall automatically route the approval of a purchase requisitions to a pre-designated signing authority for a particular unit”.

Requirements should also be prioritized during the analysis process. This is typically achieved by categorizing and weighting each requirement with customer input and the cost-benefit ratio of the requirement. For example:

Requirement Priority Description
Must Have A “show stopper” requirements, without which the solution is of little use or benefit
Preferred Demonstrable efficiency, cost savings, or income producing requirement
Optional Intangible or small benefits only; cost >= benefit)
Cancel Too complex or costly, or no value add

IT solutions for a particular customer problem or opportunity will have three major aspects that need to be considered during analysis: Process, Data and Behavior. Process refers to the work activity and steps that the solution needs to support. Data refers to the information and facts to enable the process. Behavior relates to the animation of the process and the interaction with the actors in the process. These aspects exist and are intertwined in every IT solution, but their weight will depend on the specific nature of the customer need. For example, a Faculty Ladder Ranking process, a Student Registration process, a facility monitoring process and a Data Mart or Decision Support System will all vary in the relative degree of data, process and behavior involved. In considering the activities in this phase the analyst must use their best judgment to build a project specific approach that addresses this variation in the problem domain.

A final consideration for the analyst is to select the data gathering approach that will be used to capture requirements. Customers may be interviewed individually, in small groups, in facilitated work sessions or some combination. The exact approach and sequencing of work needs to be determined and agreed to with the client so as to minimize disruption of their daily operations but maximize involvement of key stakeholders and subject matter experts. Since the Solution Context Diagram provides a boundary and baseline for the analysis effort, it is strongly recommended that this be developed in a facilitated work session with the broadest group of customer representatives and the Project Sponsor present.

  • Confirm User Subject Matter Experts for Requirements Definition

    The first crucial step in defining requirements is identifying those persons who understand the problem domain can speak with some authority on the needs of the client and the customer constituency. In cases where a solution will serve a large and varied number of customers it will be necessary to work with client leadership to determine a subset of customers who can adequately represent the larger set of customers who will use the IT solution.
  • Develop Solution Context Diagram

    A graphical presentation of the interfaces and boundaries of the problem area or process to be analyze should be developed. The context diagram must show all known and relevant external agents or actors (organizations, systems, roles, external processes etc.) and the major data flows in and out of the area to exchange information or to respond to events.
  • Develop Process Model

    Excellent treaties have been written to describe the development of process models and a full description is beyond the scope of this handbook. The purpose of developing a process model is to understand the work being done and the roles of the various actors in the process. In those cases where the process flow aspect of the problem domain is significant, Functional Decomposition Diagrams and Cross-Functional Workflow models should be developed with the customer subject matter experts. In simpler cases a Functional Decomposition Diagram may be sufficient to partition, decompose, and describe the activities of the area under study. The scope of the potential IT solution can be determined through examination of the current state process model and the future state or “To Be” process model that the client anticipates the new IT solution will support.
  • Develop High-Level Data Model

    A conceptual level entity relationship diagram (ERD) should be created to define the data needs of the customer and major business rules. This should include major fundamental and associative entity types, their major attributes and relationships. This should be a conceptual level ERD that is independent of a specific physical database implementation. Its primary purpose is to enable validation of business data needs, terms and business rules and to provide input to the designers and data base administrators who will build more detailed logical and physical data models for implementation. If the current situation involves an existing IT solution then existing conceptual data models can be reused or reverse engineered from the solution. The data model can also be used to capture new business rules and data needs for the envisioned solution.
  • Develop Use Cases

    Use Cases provide a transition into system design from the process model to the human-system interaction that will be supported by the IT solution. High-level “business” Use Cases should be defined that characterize the major interactions between the users and the solution. If a cross-functional workflow model has been developed, candidate Use Cases can be identified from those points at which the customer roles interact with the system to perform a task. Judgment must be applied to ensure that the Use Cases can be validated directly with the customer and yet form a basis for the development of more detailed Use Cases by the Application Developers in the System Design Phase.
  • Document Functional Requirements

    Functional requirements will be uncovered as a result of the preceding activities in this stage, through a combination of conversations with the customers and by analyzing the context model, process models, data model and use cases. During this activity, the Business Analyst simply documents these Functional Requirements in preparation for more formal requirements specification, grouping and ranking later in the stage.

2. Define Non-Functional Requirements

Non-Functional requirements encompass all the qualities that the solution must have for it to be usable, fast, reliable, secure, and attractive to users. During this stage the team will identify, group and prioritize this wide range of requirement types.

  • Identify Solution Technology Platform Requirements

    If known at this stage, the technology platform required to support the solution should be specified. It is anticipated that in many cases the solution will be an extension of an existing IT Service and so the technology platform requirements will already be known. Prevailing IT Architecture standards should also be considered during this activity.
  • Evaluate Technology Vendor (COTS)

    If a Commercial Off-The-Shelf (COTS) solution is being evaluated, its technology platform needs to be evaluated against functional requirements in this activity and the IT Architecture. In addition, the financial viability, and qualifications (references, etc.) of the vendor should also be evaluated.
  • Define Quality, Reliability, Availability, Service Level Needs

    The team should document the expectations of the solution in terms of system quality, reliability, availability windows, and the broad IT Service level needs.
  • Define Performance Needs

    The team should capture and estimate any system performance and volumetric information (response time, transaction volumes and cycles, concurrent users, dataset size and growth rate, archival needs, etc.) that can be used to define the performance needs and metrics for the solution.
  • Identify Security, Legal, Regulatory and Compliance Needs

    Any security, legal, regulatory and compliance needs should be documented and verified with the client and checked against Federal, State, UC and UCSC IT compliance policies. The project team should refer to the Security Design Package for guidance on policies that will guide classification of the system and data, and thus identify security requirements that must be met within the system design.
  • Identify IT Budget Constraints on Solution

    If there are any existing budget constraints on the solution these should be identified in this activity to guide decision making and the generation of solution options. The team should also evaluate the feasibility of meeting the solution requirements against the financial constraints and expectations of the client.
  • Document Non-Functional Requirements

    The Non-Functional requirements uncovered in this stage are documented by the Business Analyst.

3. Conduct Existing Solution Inventory and Gap Analysis

  • Map Existing Solutions to Requirements

    The functional and non-functional requirements should be mapped against existing IT services and solutions to determine if an existing solution may be reused, partially or completely, to serve the client needs.
  • Identify Solution Functional Gaps

    If an existing solution is found that partially addresses the requirements, the short comings or gaps in the solution should be noted and weighted for importance.
  • Develop Strategies to Address Solution Gaps

    In this activity the team will develop strategies and approaches to address the gaps in functionality between the requirements and the existing solution. These strategies may include 3rd party “bolt-ons” or additional modules for software package solutions, use of other existing solution components or custom development and interface development.
  • Define Solution Gap Requirements

    The solution functional gaps and the strategies to address them should be refined into a set of solution gap requirement statements to be included in the final Requirements Specification document.

4. Specify Requirements

The solution functional gaps and the strategies to address them should be refined into a set of solution gap requirement statements to be included in the final Requirements Specification document.

  • Compile Requirements

    The number of requirements captured, even in a medium sized project can be burdensome to manage and evaluate with the client team. To aid in this process, the requirements should be specified in a uniform, structured way for ease of management and evaluation. In order to facilitate this effort a requirements template has been developed based on the Volere Requirements Specification Template from the Atlantic Systems Guild.
  • Assess and Rank Requirements

    The set of requirements should be evaluated and ranked in terms of user priority and criticality.
  • Group and Phase Requirements for Implementation

    Some requirements will have logical dependencies and affinity with each other. The team should use this information, together with the requirement ranking information to group and phase the requirements for implementation sequence and perform a trade-off analysis when considering the scope of the initial solution to be implemented. At this stage, all known requirements should be captured, grouped and phased – even if they are beyond the current planned scope for the system. This is important since some cases a desired requirement in a later planned phase may influence the design of the earlier system designs.

  • Publish Requirements Specification

    In this activity, the Requirements Specification published and distributed to the client and key stakeholders for review. Document version control is important in this and later stages as feedback is received from multiple stakeholders and corrections are made. Therefore it is recommended that a single team member be assigned to manage the version control for the Requirements Specification document and recording of the approval process for agreed changes.

5. Obtain Sign-Off of Requirements

  • Conduct Requirements Review with Sponsors

    A formal review meeting should be held with the client, key stakeholders and sponsors to capture feedback on the Requirements Specification deliverable.
  • Address Requirements Review Issues

    Issues raised in the Requirements Review should be captured in the Project Issue log by the Project Manager and systematically addressed by the team. To avoid gridlock and ‘analysis paralysis”, the issues should be ranked and weighted in relationship to the prioritized set requirements. The project team and sponsor should aim to resolve all major issues before moving to the next phase. Minor issues may be deferred and addressed in solution release planning.
  • Obtain Sponsor Approval of Requirements

    Formal written approval of the Requirements Specification should be obtained from the client, ITS and executive sponsors.