We tend to say that requirement are to be elicited, still it’s the responsibility of business analyst to walk through them carefully, analyse and verify both single ones and functional bundles, as requirements like many other software development process deliverables, need to be of high quality.
What are then the determinants of high quality for requirements? Inspired by BAs Bible – Business Analysis Body of Knowledge (IIBA, BABOK v_2.0) I described below the most common criteria for requirements evaluation.
Cohesive
Each requirement should concern one and only one aspect. Embracing to many aspects within a requirement makes it confusing and not fully clear, what’s the goal to be achieved. Going further, requirements should be „atomic”, so as tiny as possible (have you heard about elephant carpaccio technique? :)). This results also in a more accurate number of requirements, e.g. for the needs of rough work estimates based on functional requirements quantity.
Complete
The meaning of completeness has evolved as Agile methodologies appeared. What does it mean? In waterfall project during the analysis phase it was really crucial to elicit all actuall requirements, even these not stated by stakeholders, but actually existing ones or those resulting from remaining requirements. The late emergence of requirements, e.g. at the stage of design, implementation or testing resulted in an increase of cost and solution complexity and related release delay. These days when iterative delivery and constant development takes place, as solutions need to permanently chase the business needs, completness is understood in a slightly different way. It concerns more project requirements, rather than the whole solution requirements. It’s also commonly known, that Agile delivery is all about iterations, therefore requirements missing in one cycle, will be most probably noticed during demo or Sprint review and raised properly. Additionally solutions design approach has changed to enable permanent development. Software applications are not monoliths any more, but they are built e.g. as a set of interacting microservices, which are easier to maintain and develop.
Consistent
Talking to different stakeholders we may really often elicit contradicting requirements. That’s a huge responsibility of Analyst to identify such cases and help to resolve them in a way aligned to the higest business value. It may also happen that two separate requirements describe overlapping functionalities in a conflicting way. In such situation, one thing would be to get back to requirments atomicity and make them smaller or assign particular functionality to just one of them as well as describe it in a single way. Extremely important is to set requirements relations and track these dependencies. It might happen that update in one requirement implies need of adjustments in other requirements. Tools bring you plenty of support for maintaining relationships, starting from simple links in MS Word up to advanced link types in Atlassian Jira. It’s also important to keep comparable size of requirements. If one ot them significantly differentiates from the others, maybe it’s not atomic any more.
Correct
I’m not sure, if that one needs even a short description. I think that all Analysts with few years of experience, who have participated in Users Acceptance Testing or go-lives as opportunities to see how actually developed stolutions start to be operative, are fully aware of the fact that wrong requirements are the beginning of problems. They are even worse than missing requirements, as they concume time, money, energy and enthusiasm of the team. You should be aware that small issues may always occur, but for more high level requirements, it’s crucial to confirm, that we are going the right way. There are plenty of techniques to confirm requirements correctness with stakeholders, as 5 whys, prototypes, requirments walkthrough etc.
Feasible
Each requirement needs to be possible to implement. Sounds obvious, doesn’t it? It concerns both functional and non-functional aspects. Once my programmer colleague, frustrated with something I had stated in requirements document, said to me that MS Word will compile everything and that’s actually true. What I should have done better was to perform a broader AS-IS analysis of current functionality, as I wasn’t aware of how complex it was. Apart from functional aspects, we should always have non-functional perspective in mind. This is where close cooperation with Solution Architect starts to matter. Both in building new solutions and develeping new capabilities in existing ones we should consult with Architects to make sure, if what we are stating as requirements, is feasible in terms of performance, security, scalability etc.
Modifiable
As mentioned a little bit earlier, related requirements should be easy to track. It allows to perform impact analysis more smoothly. When you, as a BA, receive a change request, while looking at the requirement dependencies section, you can more easily build your own understanding, of how big the change really is. As an intern in my first job I got a task to document change request for increasing the lenght of some field. At first it looked a little bit non-ambiscious task, but as soon as I have started talking to development team, I understood how tricky this requirement was. It would influence over a dozen of forms, reports as well as algorithms. The document I had elaborated was of several dozens of pages and as a result Customer resigned from changing the field. It had been good that I could talk to the team, but actually it should have been documented properly at first, so that I was able to get to dependencies by myself.
Unambigious
Have you ever read your requirement after some time and either couldn’t understand them at all or came to completely different conslusions from those that you actually had aimed at ?? It happens. When you are immersed in domain learning and requirements analysis process, you can actually get to details so deep that you loose the big picture. Here come with help peer reviews, grooming or requirements refinement in general and other techniques. If you walk through requirements with the team and you see that particular members of the team do not have the common understanding of the requirement, it’s a big signal to revise them and either make them either simpler or add some context information, like what module or enties does it concern, what business situation and system conditions is it about etc. Maybe you should make sentences less complex. And finally, revise your own requirements by yourself from time to time, if that’s possible.
Testable
Testers are great requirements auditors. Not only are they capable of finding gaps in requirements, but also as they are obliged to elaborate test cases based on requirement, they can perfectly assess, if requirement is actually testable. Of cource it does not concern high-level business requirements, which most often oscillate on the business process level, but rather detailed use case flow or specific user story. In these techniques s a brilliant way to make requirements testable, is to write well formed acceptance criteria, preconditions, what is the main flow and alternative ones, what is the expected result and exceptions. This is the level of detail that you should deliver. If you’re not sure, whether your requirements are testable enough and you can’t afford asking testers all and all over again, put yourself in tester’s shoes and this will allow you to realize, what kind of information is still missing.
I hope that described above aspects will help you to work over quality of your requirements, regardless of whether you work in classic, waterfall environement or more flexible, agile model.
Still, please remember, that apart from meeting all above mentioned characteristics, requirements must also address the actual business need. So whenever stakeholders come to you with system requirements, at first make sure, that solutions which they expect are thought through and will solve the real business problem. Cause even the best written requirement won’t deal with business issues, if business objectives are not known enough.
Leave a comment