When I just graduated from university, I joined Fsoft as an offshore Business Analyst (BA). I, a fresher who don’t even have IT Background, started learning and working from scratch. I spent 3 days learning about SharePoint as it’s the platform our company normally work with. After that, I joined a project and got started with my very first Software Requirement Specification (SRS) – the main output of Business Analysis task.
Well, I was given a SRS and a site. My goal was straightforward: to update the SRS so that it reflects exactly what the site is working. It’s not hard, even with a newbie, if someone gives you the short instruction about how to read and to update a SRS (indeed, the onsite BA did guide me through). In the next 2 years, writing SRS was my main job, so I did ask myself: “SRS will surely be my companion in the long journey, shouldn’t I get to know it a bit more?” And it’s how I started.
As all other type of document, there must be Introduction (Pre-face), Content and Appendices parts inside a SRS. The main thing is how we incorporate requirement into it.
According to International Institute of Business Analysis (IIBA), requirement in general is classified into 4 categories:
(Sizwe Dumisani. 2014. UML Diagram of BABOK v2 Requirement Classification. [Online]. [Accessed 29 April 2017]. Available from: http://www.potomacprojectservices.com/blog)
- Business Requirements: this kind of requirement is quite general, it states objectives, goals or outcomes of the change – or the system/ application/ etc. Normally, this requirement is documented in Introduction part – it will tell reader exactly purpose of the system being implemented. Through my experience, many people underestimate the important of this part, and so did I. However, just stop for one second and ask yourself: Where should reader go if they want to know about the system? Where do you normally go when you first read a book in a brand new field? I believe you have your own answer. Sometimes, there is only one short sentence in this part such as “The system is used to manage User Accounts”. Accurate, but not detail enough. What do you mean in “manage”, why do people have to initiate the system? Every change must initiate from a need.
- Stakeholder Requirements: this kind of requirement is more detailed than the Business Requirement. It will introduce who works with the system (e.g.permission matrix, use case diagram) and how to work (e.g. workflow, state transition diagram), but just in high-level. A picture is worth a thousand words. Hence, with something overview like this, BA normally use “picture”. BA has many tools to create their own “picture” – but it should follow some standards of Unified Modelling Language (UML).
- Solution Requirements: this kind of requirement once again is classified into 2 sub-categories:
- Functional Requirements: BA normally pay most attention on this kind of requirement. All functionalities of the system are described here in as much detail as possible – using Use Case Scenario or User Stories approach. Whatever approach you are using, this section must identify who do what for which purpose, as well as all possible ways to achieve that purpose.
- Non-functional Requirements: this kind of requirement is very important even though it does not describe functionalities of the system. However, it is strict conditions must be satisfied for the system to work effectively. I experience one project in which Development team has to spend a lot of time migrating the existing code to another platform, as they chose the wrong one at the first place. The root cause is because of lacking of the Non-functional Requirement.
- Transition Requirements: many of my colleagues don’t recognise this kind of requirement. In BABOK version 3.0 issued by IIBA, Transition Requirement is defined as “the capabilities that the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete”. This kind of requirement is only temporary, including data conversion (such as Data Migration, Interfaces with other systems), training and business continuity (these two are not very familiar). If you are interested with further information about this kind of requirement, please go to http://enfocussolutions.com/transition-requirements.
Now, when we come here, the structure of a SRS can be formed by our own. On the other hand, you should be confident that you can create a SRS Template by standard. For each project, the template can be modified, but the main skeleton must remain to keep the requirement accurate and enough.
I will entail on each type of requirement in the next post “Specify and Model Requirement – How we write a SRS?”
- IIBA. 2015. BABOK. Version 3.0.