Requirements analysis

People make new things like tools or computer programs.

Before they start, they must plan. They talk to people to find out what is needed. They might watch how people work. They can even make a small model to show ideas. This model is called a prototype. It helps people see what the new thing will be like. This plan makes sure the new thing works well. It is a very important step.

When people build new tools or software, they must plan first. This work is called requirements analysis.

Analysts try to find out exactly what a project needs. They look for the needs of stakeholders. Stakeholders are people or groups with an interest in the system. This might include the people who use it. It could also include people who buy it or regulate it.

There are three main steps in this work. First, they gather information. They might use interviews or watch how people work. Next, they record the needs. They might write them in lists or use stories. Finally, they analyze the needs. They check if the ideas are clear and match each other.

Sometimes, analysts make a prototype. A prototype is a small model or example. It lets people see how a system might work. This helps people make good choices before the real work starts. Analysts also use use cases. A use case is a way to show how a person uses a system to finish a task. These steps help make sure the final product works well.

When people build new software or machines, they must plan very carefully. This important work is called requirements analysis.

It focuses on finding out exactly what a project needs to succeed. Analysts look for the needs of different stakeholders. Stakeholders are people or groups who have an interest in the system. This includes the people who will use it or the people who buy it. It can even include groups that regulate how the system works. Doing this work well is critical to a project's success or failure.

Requirements analysis works through three main steps. First, analysts perform elicitation to gather information. They might hold interviews or watch how people work in their daily jobs. Next, they move to recording the requirements. They might write these down in lists, use cases, or data models. Finally, they must analyze the requirements they have collected. They check to see if the ideas are clear, complete, and consistent. This step helps resolve any conflicts between different needs.

In the 1990s, a major new emphasis was placed on identifying all stakeholders. Analysts realized that stakeholders are not just the people paying for the project. They include anyone who operates the system or benefits from it. This includes people who handle maintenance or those who purchase the system. In large companies, marketing and sales teams act as helpers to guide development. Even people who might oppose a new system are considered stakeholders. This helps ensure that everyone's needs are understood from the start.

There are many ways to document these needs. One traditional way is using contract-style requirement lists. These can be hundreds of pages long, much like a huge shopping list. While these lists provide a helpful checklist, they can be hard to read. They often lack context and do not show how ideas fit together. Because of this, many people now prefer using agile methods. These methods use user stories, which are written in everyday language. This makes it much easier for everyone to understand the goals.

Analysts also use special tools to help people visualize a project. One great tool is a prototype, which is a small model of a system. A prototype might be a working program or a simple drawing called a wireframe.

These models let people see how a system might look before it is built. Another tool is the use case. A use case describes the steps a person takes to finish a task. These tools help prevent expensive mistakes and make communication much better.

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.