Requirements are descriptions of various needs of a software system from the perspective of the organizations or individuals who will use the system. They are typically written in the form of one or more documents prior to the beginning of software development and are used to give direction to programming teams. It's important that requirements be defined accurately, completely, and unambiguously. This isn't always possible, and some software development workflows prefer iterative progress over tightly constrained requirements, but generally the more information and detail the programmers can be given before the start of a project, the more the final product will be in line with expectations.
Software requirements are sometimes gathered and segmented into more specifically titled documents, such as user requirements, functional requirements, and technical requirements.
Once software requirements have been documented, the next steps of the software development process can be planned, including costs, staffing requirements, and milestone dates. After analysis and planning, software specifications can be written to direct the development team. There's often confusion between specifications and requirements. The requirements are the "what" and the specifications are the "how". Requirements should not contain any technical implementation details. The two complement each other but gathering and documenting requirements always precedes writing specifications.
 Gathering Requirements
Gathering functional requirements are a critical step in the software development process. Only with this information can documents be written, contracts be signed, and software be built. Any lapse in requirements may frustrate users and interested parties. Requirements added late in the development cycle will alter the deliver schedule and introduce bugs. They might also require architectural changes and refactoring.
When coming up with the requirements for any software system, every possible use case should be considered.
Requirements are organized into one or more sections, depending partly on the depth of the information and type of system being built. There is at least one official standard for organizing requirements (by the IEEE) and other conventions are favored by some project managers and organizations.
An introduction to a requirements document should include a project summary, explain its purpose, list the stakeholders and organizations involved, and itemize any related documentation. Elaborating on the business motivation for building the system is helpful in conveying the reasons certain choices are made and to keep everyone involved focused on the primary goals.
For example, a requirements document for a website may explain the intended audience, a summary of what information it will display, and references to design draft documents. In another example, an introduction to a new mobile game application might summarize the storyline, devices targeted, and revenue model.
 Scope and Constraints
Another section of a requirements document should explain the scope, constraints, and assumptions of the software system. These provide focus and boundaries which explain the limitation of features. They can also help prevent scope creep - when new features are proposed in the future they can be countered against the intended scope of the original project. A list of constraints is also critical during programming so time isn't wasted going down an unintended path.
 Naming Conventions and Terminology
Many systems develop their own terminology for solving specific business problems. By elaborating on the conventions and terminology used in describing the system, confusion can often be avoided. It also ensures consistent terms are used throughout every conversation when describing features.
 Data Model and Data Requirements
Many requirements specifications include a data model, either specific to the system's data architecture or described at a business level. For example, requirements for a content management system may explain the attributes of a basic page, such as the time created and a reference to the author's information. Also any dependencies on the data model should be explained, such as 3rd party sources or what is expected to be input manually by users.
Data modeling during the requirements phase of the software development process differs from the specifications phase. During the software specifications process, data storage systems are chosen, record field attributes are itemized, and other technical choices are made. But earlier in the requirements gathering process, the data model is only explained at a level that solves the business needs. For example, a requirements document might list the fields of a user's address: street, city, zip, etc. Later during the specifications phase those fields will get system names, data types, storage solutions, indexes, etc.
 Functional Requirements
Functional requirements are where business processes and workflow are explored in terms of how they would be mirrored in a software system. It takes a person with a deep understanding of both the business processes and a computer system's capabilities to gather and document functional requirements.
Functional requirements refer to the specific actions and processes which are to be implemented in a software system yet to be created or updated. These are sometimes written into a separate software specifications document once these needs are formalized into system workflows, algorithms, and formulas. Developers then use the specifications as a primary reference when programming the software.
For example, a client may ask for something simple: "Registered users may enter their address." The functional requirements could be stated as: "Registered users may optionally add or edit one or more addresses associated with their account. Addresses are listed on the account detail screen. The edit form is a popup with fields for street, city, ...". The functional specifications would then state how a user becomes registered, where in the application they may enter an address, the input fields that comprise the address, input validation logic, and the data model and systems used for storage.
 User Interface Requirements
The look and feel plus usability necessities of a system are often explained. This may be separately encompassed in a design document.
 Performance Requirements
Systems are most often required to work within certain performance metrics. These must be defined in some way for a system to be architected appropriately. For example, a common website performance requirement is for each page to be generated in under two seconds.
 System Requirements and Dependencies
Requirements may also refer to the hardware and software that's needed in order to properly run a software system.
For example, the requirements for a new desktop application within an organization will most likely need to list the operating systems, common software packages, and networking already in use. The new application will need to operate within the existing environment. Or new requirements for the organization's existing systems might need to be chosen if the new application can't operate within the existing environment.
 Platform Requirements
Hardware requirements often include CPU, RAM, storage, and input devices needed to run software. For example, any operating system will have all of these minimum requirements listed. Often applications will also list these requirements, in addition to the other software required to operate properly. A text editor, for example, would list the operating system and other software packages that are needed for it to run.
Minimum requirements refer to the smallest, slowest, or oldest hardware or software which are needed to operate properly. For example, a minimum RAM requirement would mean at least that much should be available. A minimum CPU requirement would mean a slower chip would not perform well, but a faster or newer chip of the same family or instruction set would suffice.
Many systems interact with others through APIs on the local or external systems. These can be necessary for complete functionality. For example, a web application might require payment processing through a payment gateway. During the requirements gathering phase these 3rd parties should be chosen.
Later, during the software specifications phase, the specific API calls and versions can be itemized.
 Security Requirements
Security considerations may be itemized within the functional requirements since they're often related to the user workflow, but they can also be listed separately. Security requirements should include system level details, such as how the software will be locked down to prevent attacks.
 See Also
- Robertson, Suzanne; James Robertson [August 16, 2012]. Mastering the Requirements Process, 3rd Edition, Addison-Wesley Professional. ISBN 0321815742.