When defining requirements, many people become confused when they attempt to differentiate between business requirements, user requirements, and software requirements. All three types of requirements are different and serve different purposes.

Business requirements describe why the organization is undertaking the project. They state some benefits that the developing organization or its customers expect to receive from the product. Business requirements may be delineated in several documents such as a project charter, business case, or in a project vision and scope statements. Business requirements bring the project owner, stakeholders and the project team on the same song sheet.  But you can’t build software from such high-level information. In the Enfocus Requirement Suite, ™ we consider the following business requirements.

• Problem Statement
• Project Vision
• Project Constraints (Budget, Schedule, and Resources)
• Project Objectives
• Project Scope Statements
• Business Process Analysis
• Stakeholder Analysis

The results from the business process analysis and stakeholder analysis activities are also considered business requirements. The purpose of the business process analysis is to determine how the business process will work.  It is often necessary to resolve deficiencies in the business process before trying to automate it.  Not dealing with the business process design first is like trying to pave a cow path; it might get you there, but it certainly won’t be the straightest most direct path. The stakeholder analysis is needed to determine who will be impacted by the system and how to engage the impacted people to get their user requirements.

User requirements, often referred to as user needs, describe what the user does with the system, such as what activities that users must be able to perform. User requirements are generally documented in a User Requirements Document (URD) using narrative text. User requirements are generally signed off by the user and used as the primary input for creating system requirements.

An important and difficult step of designing a software product is determining what the user actually wants it to do. This is because the user is often not able to communicate the entirety of their needs and wants, and the information they provide may also be incomplete, inaccurate and self-conflicting. The responsibility of completely understanding what the customer wants falls on the business analyst. This is why user requirements are generally considered separately from system requirements. The business analyst carefully analyzes user requirements and carefully constructs and documents a set of high quality system requirements ensuring that that the requirements meet certain quality characteristics.

System requirements are the building blocks developers use to build the system. These are the traditional “shall” statements that describe what the system “shall do.” System requirements are classified as either functional or supplemental requirements.  A functional requirement specifies something that a user needs to perform their work.  For example, a system may be required to enter and print cost estimates; this is a functional requirement.  Supplemental or non-functional requirements specify all the remaining requirements not covered by the functional requirements. I prefer to use the term supplemental requirements instead of non-functional requirements; who wants to be termed nonfunctional? Supplemental requirements are sometimes called quality of service requirements. The plan for implementing functional requirements is detailed in the system design. The plan for implementing supplemental requirements is detailed in the system architecture.  The list below shows various types of supplemental requirements.

• Accessibility
• Accuracy
• Audit, control, and reporting
• Availability
• Backup and restore
• Capacity, current and forecast
• Certification
• Compliance
• Compatibility of software, tools, standards, platform, database, and the like
• Concurrency
• Configuration management
• Dependency on other parties
• Deployment
• Documentation
• Disaster recovery
• Efficiency (resource consumption for given load)
• Effectiveness (resulting performance in relation to effort)
• Emotional factors (like fun or absorbing)
• Environmental protection
• Error handling
• Escrow
• Exploitability
• Extensibility (adding features, and carry-forward of customizations at next major version upgrade)
• Failure management
• Interoperability
• Legal and regulatory
• Licensing
• Localizability
• Maintainability
• Modifiability
• Network topology
• Open source
• Operability
• Performance/response time
• Price
• Privacy
• Portability
• Quality
• Recovery/recoverability
• Redundancy
• Reliability (e.g., mean time between failures – MTBF)
• Reporting
• Resilience
• Resource constraints (processor speed, memory, disk space, network bandwidth, etc.)
• Response time
• Robustness
• Scalability (horizontal, vertical)
• Security
• Stability
• Safety
• Supportability
• Testability
• Throughput
• Usability

A solution may contain only software components, or it could incorporate both software and hardware components. It may also include training and organizational change requirements that will be provided to instructional designers to develop a comprehensive training program. Software requirements represent the system’s functional and supplemental requirements that define the software components of the system.

Traditionally, functional and supplemental requirements for software were documented in the software requirements specification (SRS). The SRS is the principal deliverable that analysts use to communicate detailed requirements information to developers, testers, and other project stakeholders. Many modern systems, such as the Enfocus Requirement Suite,™ place requirements into multiple requirement bundles to support iterative development and to break requirements into various components required by teams to develop the solution (e.g., software, hardware, organizational change, etc.) Requirement bundles provide more flexibility than URD and SRS.  Requirement bundles may be developed iteratively and incrementally with both stakeholders and project team members being able to validate and review the requirements as they evolve. User needs are always mapped to system requirements so that the developer sees not only the requirement but the source from where it originated.