Requirements analysis

Requirements analysis is a vital process in systems and software engineering. It focuses on determining the specific needs or conditions required to create a new or altered product. This process is critical because it can determine the ultimate success or failure of a project. Analysts must account for the possibly conflicting requirements of various stakeholders. They work to analyze, document, validate, and manage these requirements throughout the project lifecycle. To be effective, requirements must be actionable, measurable, testable, and traceable. They must also be related to identified business needs and defined with enough detail to allow for system design.

Conceptually, the process involves three distinct types of activities. The first is eliciting requirements, which is often called requirements gathering or discovery. This involves creating a project charter, documenting business processes, or conducting stakeholder interviews. The second stage is recording requirements. Analysts document these needs in various forms, such as natural-language documents, use cases, user stories, or process specifications. They may also use complex data models. The final stage is analyzing requirements. During this step, analysts determine if the stated needs are clear, complete, concise, and valid. They also ensure the requirements are consistent and unambiguous while resolving any apparent conflicts.

To gather information effectively, analysts employ several different techniques. They might develop scenarios, which are represented as user stories in agile methods. They may also use use cases or perform ethnography, which involves workplace observation. Other methods include holding interviews or conducting focus groups. In a professional context, these focus groups are often called requirements workshops or review sessions. Analysts might also use prototyping to develop an example system for stakeholders to see. By combining these methods, an analyst can establish the exact requirements needed to meet business goals.

Identifying stakeholders is a major component of modern requirements analysis. A stakeholder is any person or organization with a valid interest in the system. Since the 1990s, there has been a major emphasis on identifying all possible stakeholders. This includes anyone who operates the system, such as normal or maintenance operators. It also includes functional, political, financial, or social beneficiaries. Other stakeholders include those involved in purchasing or procurement. In mass-market organizations, product management, marketing, and sales act as surrogate consumers to guide development. Even regulators and people who oppose the system are considered stakeholders.

One traditional method of documentation is the contract-style requirement list. These lists can be extremely long, sometimes running for hundreds of pages. You might think of them as an incredibly long shopping list. While they provide a useful checklist and a contract between sponsors and developers, they have significant weaknesses. They often lack context and do not show how different requirements work together. Because they are so abstract, removing one item might make an entire business requirement useless. Many modern teams now prefer agile software development. This approach uses user stories to suggest requirements in everyday language.

Analysts also use prototypes to improve communication and decision-making. A prototype is a computer program that shows some properties of a larger system. It allows users to visualize an application before it is fully constructed. A popular form is a mockup, which helps stakeholders see what the system will look like. Prototypes can be flat diagrams called wireframes or working applications with synthesized functionality. Wireframes often use a greyscale color palette to prevent confusion about the final visual design. Using prototypes early in the process can reduce overall costs by leading to fewer changes later.

Another important tool is the use case, which is a structure for documenting functional requirements. A use case provides a set of scenarios that show how a system interacts with a human user or another system. These are designed to achieve a specific business goal using the language of the end-user. Use cases are deceptively simple, but they should not describe the internal technical workings of the system. Instead, they show the steps needed to perform a task. Finally, the process often leads to requirements specification. This is the synthesis of discovery findings that moves an organization from its current state to a desired future state.