Requirements Practice: Different Requirements Processes for Different Project Situations

In this article I will describe three different requirements processes that co-exist in one IT department for three different project situations respectively. The three processes distinct from each other in some small ways. Firstly, those who write the requirements documentation are different groups of people. Secondly, there are different levels and amount of user involvement and also IT development team’s involvement. Thirdly, there are different levels of details contained / required in the requirements documents.

To begin with the introduction of the three requirements processes here let me explain some background information. The projects that the IT department works on are mainly in-house development. And the main systems involved include ERP systems and e-Commerce tools used by customers (direct customers, resellers, partners, distributors). Process P1 is the process for IT project prepackaging where the main output contain: a Business Requirements Specification (BRS), a High-Level Design (HLD), a High-Level Estimation (HLE), and also a resource / capacity planning and budget control.

Project situation one: normal IT projects that go through P1 – this type of projects constitutes the majority of all IT works.

Corresponding requirements process and requirements characteristics: Typically, four main stages of work are involved in this process: preparation, requirements workshops, requirements reviews, and sign-off. In the preparation, the main tasks include understanding the project request documentation. Then the requirements workshops are led by the BAs to elicit requirements with various stakeholders (mainly from other departments within the organization, e.g. Sales, Finance, Services, specific application teams – those applications are ones that will be affected by the project). The requirements process is conducted by Team BA (Business Analyst), but in the course of defining requirements, no development team is assigned to that project yet.

For this type of projects, requirements in BRS might end up to be very detailed if

  • the Application Team involved knows very little about the system(s) in scope because then they will ask BAs to specify every detail step by step;
  • or if the business team (e.g. from Services, Finance) know very well about the system(s) in scope because then they would provide so much detailed information to the BAs – they could even do the BAs’ job to specify the requirements…

Or the requirements might be much less-detailed if the application team (usually the technical lead) say that they know very well about the system(s) in scope and they would like BAs to treat those system(s) as black box. Hence it is only those relatively high-level requirements needed to be specified.

Project situation two: Special IT projects that are very important or urgent that could not wait to go through P1 and then will go through a Fast Track.

Corresponding requirements process and requirements characteristics: The process should be similar to the process for project situation one.  And the requirements are done by folks from the Team BA as well. But it seems the business and the BAs are working more closely with the development (to be confirmed this later).

Project situation three: Special IT projects that are based on the Voice of Customers, which are usually small enhancements to current tools and will release in a monthly basis.

Corresponding requirements process and requirements characteristics: The process for doing requirements in this situation looks simpler than the other two types of projects, partly because the scope and volume of requirements are much smaller. Requirements are documented by an individual that is always responsible for this one iterative project but he is not managed by Team BA. He takes over some initial set of requirements (prioritized already) from the folks responsible for the Voice of Customers. Then he works with corresponding stakeholders to discover and decide on requirements details. The resultant requirements documentation is called BRS and is supposed to follow the BRS template. But in reality the real BRS for these projects are very different than those in the other two project situations. There is usually no use case in the BRS and the requirements are much more technical. All too often, there is no one single core application that the BRS will focus on since it is enhancements towards all current tool used by customers. Very often, there is even a developer assigned for each enhancement to be made.