Software requirements provide us with the means to define and describe the purpose, value, and scope of software-based projects which are undertaken to address and satisfy some perceived need. Over the years, many definitions have been penned for what a software requirement truly must be, and what makes a “good” requirement, so there are no new revelations to be found here, no new rocket science, just some common-sense thoughts.
Ultimately, we need to ask and answer the following questions:
- Why are we doing this project?
- What is its value to us?
- What is it supposed to do?
- How do we know it’s correctly doing what it’s supposed to do?
- How sure can we be that it will keep working correctly?
Software requirements will help us address and answer these (and other) questions. Software requirements provide a description, a codification, a specification of a software-based solution to be implemented to address and satisfy a perceived need. They provide descriptions of how the overall and underlying system should behave, and how well, at various interaction levels: user, software and hardware. They may characterize system attributes or properties and they may be expressed in terms of rules and constraints.
Business Requirements
Software projects are undertaken to satisfy some organization-defined set of needs. These needs are articulated in the form of business requirements. While not hard-core software requirements, business requirements provide the “why” for the software project. Business requirements lay out the anticipated value or benefit that the organization and its serviced community expect to receive from the software project. For example, business requirements might address a software vendor’s goal of providing a readily-accessible, secure means for a government contractor to perform, document and manage procurement system compliance reviews. Business requirements are typically documented in organization vision and scope, project charter, business case, or marketing requirements documents.
User Requirements
To achieve its underlying business requirements, the software project must capture the tasks/actions that the users will need to perform. User requirements provide this level of project scope and focus: they provide the “what” for the software project. The user requirements address the tasks that can be performed and their expected outcomes. For example, user requirements might define user capabilities to perform procurement-process reviews, document the results of these reviews, refer them for additional review or approval and generate metrics-based reports. User requirements may be represented in many ways, depending on the software engineering methodologies employed and the processes/tools used to capture, record and manage them. Among these representation frameworks are use cases, user stories and event-response tables. A user story might be: “As a procurement manager, I want to be able to “Approve” a procurement-process file review that has been referred to me for a decision.” Software requirement management tools allow you to organize and group requirements into documents to provide ready reference and use as a collaboration tool throughout the life of the project.
Functional Requirements
The user-level experience may need to be described in terms of what the developer is supposed to build. This task falls to functional requirements: they too provide the “what” information for the software project, but in detailed terms relevant to a developer. For example, a functional requirement might be: “The system shall require an approving manager to select one of three approval decision options: Approve, Disapprove, Defer.” The primary audiences for functional requirements are developers and testers. As a recommended good practice, each functional requirement should be accompanied by a test case that can be used to unambiguously verify if that requirement has been met.
Business Rules
Although they aren’t software requirements, business rules may include organization policies, government regulations, industry standards and computational algorithms. Business rules may impact the scope of planned functionality in order to accommodate system enforcement or compliance with those rules. Business rules may restrict who may perform certain user functions, or control application processing based on specific combinations of data values and system states. For example, a business rule might call for a type of procurement document to be prepared and reviewed for sufficiency only if the dollar value of the procurement exceeded a specific threshold.
Non-Functional Requirements
Quality attributes are non-functional requirement which describe characteristics of the software application important to the people who interact with it: users, developers, and maintainers. Among quality attributes are usability, performance and efficiency. Other non-functional requirements may pertain to an external interface between the software system and the outside world: other software, hardware, communications interfaces/protocols and human users.