Managing Software Requirements

Companies in the software industry are possibly the ones with the most unstructured approach when it comes about processes. Almost every concerning activity in the operation of building software it’s not define. And I can say for sure, that every company that builds software has a different way of doing things.

This is not a bad thing. We see companies every day producing good software. They can have different ways of gathering requirements from clients, making designs, constructing the software and performing the tests, but at the end, the objective is one, having good software.

Today we have different development methodologies and everyone feels comfortable with one. You have Code And Fix in one way, then you have Scrum, the Agile software development and also RUP (Rational Unified Process). Each methodology preaches for something different in building software and a different process for each stage in the software development process.

A formal process for gathering software requirements can be taken from any of the previous methodologies. Let’s take for example RUP (with no preference).

The requirements process begins for example by filling out a form in which we can enter who the client is (in internal software development teams, the client can be a department in the company). We can also enter the name of the project, responsible, etc.

The second activity is a question, is this a new system? If it is a new system then we have to make a list of specific questions for gathering the requirements and also produce a set of documents for the project. If it is not a new system, then we may have some documents already define. Then, what we have to do is define the stakeholder needs in the project. This will be the client real needs, what they are trying to target with this system. This is define in a set of meetings or some other kind of interchange with the client.

The next activity would be to verify if the requirements gathered are in accordance to the stakeholder needs, if it is what they are looking for. This can be done in a series of a meetings also between the stakeholder and the system analyst. If they are not correct then we need to repeat the whole process again, just to get the right requirements.

If they are correct, the we can continue with the next step of managing the scope. Is our department ready to handle the workload of this software product? Is it to big? Is it out of scope? If it is then we have to get together with the stakeholders and review the scope of the system and repeat the process until we have something to work on.

After the requirements have been well specified and are inside the scope, we can then proceed to the activity of prioritization of the requirements. This can be done by the Software Architect. At the end, what he will do is prioritize Use Cases. After completing this activity, we can pass the requirements to the Requirements Specifier to refine the system definition.

This is a very general way to specifying requirements for a software product. Every activity mentioned here can be it’s own process. But as you can see, we really can define a process for requirements gathering. The next step will be to enforce this process within our developers. How we can do that? You can put it in a system that, instead of enforcing it, take the developers and the people by their hands and guide them through the process. You can do that using SkyXoft Procx. This process would look like this:


As you can see every activity is defined and the decisions are in place to enforce the policies. At the end, every time a new system is needed, the process for gathering requirements will be the same. You can complicate this as you want, and perfection it to your organization as needed. Not every organization is the same.