Should Business Analysts Write System Requirements?

Who should write system requirements?

In this article we will explore what a system requirement is and whether the business analyst should be writing them.

This article will answer some of the contentious questions in the business analysis space namely: should the business analyst write the system requirement or should writing system requirements be left to the systems analyst and developers?

The answer to this is throughout the article so read to the end!

System requirements vs business requirements

Before we begin, lets agree on the terms. What are systems requirements? and what are business requirements?

The BABOK ( Business Analysis Body of Knowledge) does not explicitly mention systems requirements, however we can accept that systems requirements are the functional requirements that the system has to perform in order to satisfy the business need.

The system requirements are still the WHAT the system needs to do, but also has a little of the HOW the system does it as well. And that is why it so hotly debated in the business analysis community.

The business requirements however, is in the BABOK and is defined as the statement of goals, objectives and outcomes that describe why a change has been initiated. We can therefore accept that the business requirements are the needs of the business to solve the business problem. The article Business Requirements vs Functional Requirements? Who Cares? has more on the difference between business requirements and system requirements.

Why do we debate who should write system requirements?

Business analysts have long been conditioned not to dictate the HOWs but only focus on the WHATs in their requirements. Because system requirements sometimes includes HOWs, for this reason it has been a subject of debate.

Another factor that impacts the differences of opinions when it comes to system requirements, is that the development teams want as much freedom as possible to design the solution as they see fit and it causes issues when the requirements are too restrictive. The system’s analyst/architects may also feel encroached upon when the business analyst writes very detailed system requirements.

These are issues that cause this scenario where business analysts are questioning who should write the system requirements.

A matter of how much you care

If we agree that system requirements are functional requirements of the system, then we can now answer the question: Should the business analyst write systems requirements?

The answer is that if the business analysts cares how the solution is delivered to meet the business need, then they should specify the systems requirements. However, these requirements should only be as system reactions to user actions.

If the business analyst does not care how the system accomplishes the business goal (which they may not need to care), then they should leave it to the developers to implement the solution however they see fit.

This answer does not mean that when the business analyst writes system requirements that they are to control every bit of the solution to every minute detail. The system requirements that the business analyst writes, should only be to specify what the system must do to the extent of meeting the business goals.

This means that the developers should not have to assume key features of the solution and the business analyst should not expect developers to deliver a solution in a certain way if it was never specified in a system’s requirement.

Therefore, business analysts should choose carefully what they decide to care about in the requirements they write. If how the system behaves matters that much to solving the business need, then write the systems requirements. But if the business need is satisfied regardless of how the developers code it, then there is no need to write system requirements.

Here’s an example to illustrate this.

Case study example

You are the business analyst working on a real estate lead generation mobile app. Your client wants the app to capture user information as well as the type of real estate they are interested in. If the user wants to rent then they are sent into a rent funnel that will show them further relevant information. If the user wants to buy, then they are sent to the buy funnel that shows them further information on home purchase. These funnel are existing functionalities.

You are tasked with writing the requirements for this scenario.

How would you do this?

You definitely need business requirements but do you need system requirements?

That’s the question. Lets see…

High level business requirements

The high level business requirement (HLBR) could be this:

1. The solution must capture leads by allowing individuals to provide their personal information and the real estate type they are interested in. Based on the real estate type chosen, they should be sent to the appropriate sales funnel.

Business requirements

The business requirement could be:

2. The user must be able to enter their name, email and telephone number
3. The user must be able to choose the real estate type of either ‘Rent’ or ‘Buy’
4. The user must be directed to the rent funnel, if ‘Rent’ is chosen or to the buy funnel if ‘Buy’ is chosen.

Knowing when the business requirements is enough

So far we have not written any system requirements. In fact I’ve not mentioned system at all.

These are business requirements only and they are all actions that the user takes. For this simple example, this might be enough. You have written your business requirements and you don’t need to care about how it is implemented.

In this example, writing system requirements is not necessary and so you can hand it off to the development team as it is. Of course this is a simplistic example and in a real scenario you would add your flow diagrams and UML diagrams among other artifacts. However, for the purposes of illustration, your requirements are essentially done at this point.

Knowing when to include system requirements

Now what if the client comes back and says that they notice their customers are impatient and will abandon the process, so they want to be as intuitive as possible and help the user by avoiding common errors. Also in addition to showing the appropriate sales funnels when the real estate option is chosen, they want to send the user’s data to an external CRM system as well.

Now you have to care how the system is solving the problems. Now you care about what the system is doing and how. At this point you should write system requirements.

However, the system requirements you write will always be a high level guide for the developers and not a detailed SRS or system architecture or design document. It should never have minute details of implementation. The system requirements that a business analysts typically writes are not at a detailed programmer level, but rather high level system functionalities.

System requirements

So in our example, the system requirements would be something like this:

1. The system must mask the input fields to allow better presentation of the form data. This includes showing placeholders for phone and email fields.
2. The system must evaluate that the values entered in the input fields are valid for the field type and if not, display an error message below the field.
3. When the user selects the Rent or Buy option, the system must display the appropriate sales funnel and must also send the personal information data to the external CRM system XYZ.

Now you have your systems requirements. You only wrote them because you needed it based on the business needs.

Is writing systems requirements crossing over into design?

Do you think the system requirements above crosses over into design? I don’t think so. It is simply stating what the system must do in a way that the programmers can interpret and code.

System requirements crossing over into design is something that the business analyst community feel strongly about and was well argued in the article by Karl Weigers: The Fuzzy Line Between Requirements and Design. In this simple example above, the business analyst would have provided guidance as to the functional requirements of the system without dictating the design.

When to write system requirements

Our example is simplistic and I recognize that in the real world projects are much more complicated than this, but for the point of illustration, we can see that what we have included comes directly from the requests of the client. This should be the guiding principle for how much we care about how the system provides the solution.

The system’s architect/analyst still has the job of figuring out the connection details and the architecture of the system, among other things. What the business analyst has written does not encroach on their role. Whereas it does give direction on how the solution is to be done, the developers still have the freedom to implement it in the best way they see fit.

So should business analysts write system requirements?

The answer is yes. Business analysts should write system requirements only to the extent of providing clarity for the business needs and only when absolutely necessary.

Please check out my other articles on business analysis and feel free to comment on this article as well if you found this content useful. Thanks!