Gathering Requirements

Requirements are the detailed specification of the product so that the business or project initiator can reach his or her goals by using the product(s) resulting from the project. Depending of the domain (building, IT, reorganization…) the techniques used are different. However the goal of the activity is the same.

First phase: defining the goals

Whatever project you are asked to realize, the goals of the initiator are the red route for all that follows. These goals are not what you will do, but what you want to achieve.

Building your home, your goals can be:

• A comfortable place to live with your household;
• An energy saving construction;
• Show off, to impress all that see your home …

or any combination. With these goals you will contact an architect who will help you to describe your requirements in detail. Based on his experience he can illustrate alternatives so it is easier to choose.

Building an intranet can have as goals:

• Reducing the cycle time of certain activities;
• Enhance the collaboration and efficiency of co-workers;
• Reduce the number of information requests for your helpdesk, so that they can spend more time solving real problems instead of losing time on trivial questions;
• Enhance the employee satisfaction …

or any combination. The goal is not to build an intranet, building the intranet is what you will do.

The goals for an e-commerce system can be:

• Diversification
• Better competition
• Modern image of the company
• More profits
• New markets…

Based on these goals, the features are defined. This is a small amount (mostly four to six).

For the home, these can be:

• We want a living room, a kitchen, a garage, four bedrooms, a bathroom with built in toilet, a separate toilet and an office.
• We want a high isolation, so that the energy cost is limited.
• There must be room available for a garden, so that our dog can run around.

For the intranet, these can be:

• The intranet must be very efficient. A search box is necessary but will not suffice.
• The intranet should support self-service for most forms in HRM.
• The intranet should feature a news section, but without too much real estate.
• The intranet should give access to all relevant applications and support the single sign on. This means that co-workers sign in at the start of their shift and get immediate access to all their most used applications without restricting the access to other ones.
• The aspects that are related to each co-worker (e.g. the applications) must be configurable by the user and if possible the changes in access rights for each application should give automatic adoption of the co-workers related session.

For the e-commerce system:

• Easy to use product catalog
• Promotions, actions
• Customer loyalty program
• Easy check-out
• Opportunity to track orders…

Normally these goals are a given, they are predefined. If you do not have them, create them first. Don’t start a project without goals.

What about budget and time?

These are strict features but project constraints. They will limit the possibilities for the solution. After all we are doing projects to make something happen, to introduce a change in the business. Therefor we need time and budget, but these are not goals. A project delivering within time or budget, but not delivering what the business expects, is a failure. A project exceeding time and budget, but delivering to business satisfaction may be a success (the business will be the judge).

Phase 2: the requirements

Based on the goals described in phase 1, you must gather the detailed requirements. These are necessary to define the acceptance criteria for the product(s). As mentioned above you will use different approaches based on the domain you are working in.

It is important to keep in mind that all relevant stakeholders must be involved. These are not the same stakeholders as those for the project. For a house the stakeholders are the people who will live there, the neighbors might be stakeholders for the project, they are not stakeholders for the requirements (perhaps for the needed closures they will). For an IT system the stakeholders are the business commissioning the system, the users who will use it to perform their jobs, the helpdesk who will support it, the operations who will run it daily. The programmers and other involved people of IT are not stakeholders for the requirements, they belong to the solution.

Since all requirements come from all the stakeholders in the problem domain, you will need a balanced approach. Neglecting the users in IT systems, may result in a system that can do what it should, but hinders the users to do their jobs (e.g. usability requirements, performance requirements, availability lacking…). This can be illustrated for an IT system.

^{figure 1: Requirements framework}

The business is responsible for defining the functional and partly the non-functional requirements. You can suppose that they will involve, consult the users to have the necessary details.

The users are the source for some (becoming more and more important) non-functional requirements.

Together they make up for the requirements for the system. However this is not the end of the story. The system must be successful implemented in the using organization. This means that people must be willing and adequately prepared to use the system. If this is not done properly, the business will not reach his expected goals. The project risks to be a failure. This is the change management.

For internet systems (informational sites, e-commerce, web applications …) there are two main groups of users: the internal users (e.g. the logistic department, the customer service in e-commerce) and the external users (e.g. the customers). Change management is needed for internal users, the external users expect usability, user experience, trust, performance… Not adhering to these expectations will reduce the ultimate success of the business.

You must investigate all sources of requirements, approach it in a balanced view. It is not important to try to be complete, to know everything upfront. This is not feasible (especially in IT). Use a process (e.g. agile modeling) that allows you to discover more requirements later on. However if you define cost and time upfront, each new requirement comes at a price.

Phase 3: requirements tracing

For a building these requirements will involve the size of the rooms (based on their function), the size of the windows, the kind of heating system and isolation, where you must have power outlets, hot and cold water…

For an IT system these are mostly divided into functional and not-functional requirements. The functional requirements define what the system must do, what it shouldn’t do, how good it will work.

However, the requirements must come from the features, from the goals and even from the strategy (in a business environment). Whenever you find them, you should be able to trace them back to their origin. This traceability assures you that you will created a solution conform to the requirements and goals.

This requirements tracing should work both ways: from the goals to the solution (workpackages) and back.

^{figure 2: requirements traceability}

Remark: link to strategy

Besides some mandatory projects (e.g. legal requirements, regulatory requirements…), the business should be capable to link all projects to their business strategy. The traceability defined above can be extended to achieve this. This picture shows similarities with the strategy maps of Kaplan and Norton.

^{figure 3: strategic alignment}