How Requirement Patterns Can Benefit Your Business
Software companies increasingly have a variety of different projects to manage. Sometimes these projects are similar to one another, or at least they have some common functionality, sometimes however they are not. Overall, the majority of projects business analysts and development teams work on contain very similar (if not the same) portions of functionality, defined in the project scope.
Let’s not forget about high rotation of people, not only between different projects, but also between different companies. Not everyone involved will necessarily have a deep knowledge or understanding of the product functionality or even the business area the project is related to. For new-coming analysts, the problem of understanding the business area could be easily resolved by giving them the contextual knowledge of tasks and providing them with additional literature. This works in most cases, but what happens when they are faced with functionality that is not yet ready in the existing project, but which has previously been completed in another?
From project to project, a business analyst frequently stumbles across tasks and functionality they have previously worked on. Interestingly, despite these tasks being similar, analysts frequently start working on them from scratch each time.
Starting from scratch has its benefits, but it also increases the risk of implementing “old” mistakes or missing known limitations. When working on requirements from scratch, business analysts tend to reinvent the wheel, even though they are developing the same functionality for different projects. The process usually begins with the business analyst preparing for an interview with the customer: they build a list of questions to find out more information about the clients
When all of the above is completed after the first steps of communication with the customer, the business analyst builds the very first draft of the requirement specification. It comes as no surprise it contains a lot of blanks. Frequently, requirements are not fully defined with part of the functionality missing, requirements are vague and miss some limitations and additions related to the current system, and even wrong assumptions can be made based on an analyst’s own experience, rather than the real need of the company.
Going back to square one is definitely a good approach when the elicitation of requirements really includes new business areas or brand-new features and requires a lot of creative ideas and thoughts. This is suitable, when a client’s demand is to “make it look cool, guys!” However, making a fresh start for typical tasks and features, such as authentication or reporting, is close to what we might call reinventing the wheel. New wheels are only cool when you “pimp your ride”, but for a functionality that is similar for different projects, this approach leads to multiple problems. These problems are faced by both business analysts and anyone else who is involved in the development process. The development of every new “wheel” will always contain same work-related mistakes or missing already known items (which were also missed during work on the same projects).
All of the above leads to fundamental problems in requirement analysis: requirement elicitation cycles become long, as the document needs to be reviewed multiple times by developers, quality engineers, and, of course, the client. Very often, as a result of review, the business analyst receives their document back in order to fix unclear items or explain “obvious” things to developers. This is irritating, especially when similar tasks have already been done in another or even the same project, but were unintentionally ignored by the business analyst. Reviews are also performed within the analysts’ team in the company, so newbies sometimes have to rework and correct their specifications multiple times, because these documents were made disregarding existing team rules. All these typical-task issues are a total waste of time, which could be spent on new and more interesting functionality.
In order to provide requirements of
a better quality, with less unclear parts and in a shorter time frame, the business analyst might as well start applying the approach of Requirements Patterns.
A requirement pattern is a guide to writing a requirement of a particular type. It explains how to work on such a requirement, how it should be formulated, what parts of this requirement need to be worked on very thoroughly, and it also contains links to additional requirements business analysts should take into account as well.
Each pattern should contain a defined “Requirement structure” section; with the purpose of describing the elements and use cases for the functionality. The pattern should also include an “Important aspects” section, which introduces all of the items that need to be taken into account while working on the requirement. The “Template” section of the pattern contains the draft for the requirement, so called “Lorem ipsum” text, which could be used when passing this requirement to development. An “Additional requirements” section of the pattern lists the requirements which are usually coupled with the parent one. These requirements are often forgotten or missed, which is why having them in the requirement pattern seems to be really useful.
Prior to using requirement patterns, business analysts should figure out what exactly they need to develop. First of all, it is very important to realize that some of the requirements that the business analyst is currently working on could possibly be used in future development of the current project. Being aware that a requirement might be used in the future, the business analyst should research and find all previous artifacts and experience they had with such requirements. After all of these are found and systematized, the business analyst should investigate which requirements are only applicable in a current project and which are project-independent.
Requirement patterns could be highly applicable in all kinds of projects that contain typical tasks and functionality. For example, in specifications, requirement patterns could be used for the description of the following functional areas (all of the patterns are listed in the book by Stephen Withall “Software Requirements Patterns):
- fundamental requirements (inter-system interface/interaction, technology, comply-with-standard, refer-to-requirements, documentation)
- data requirements (types, structures, id’s, calculations, archiving)
- data entity (entity, transaction, configuration, chronicle)
- user functions (inquiry, report, accessibility, ui, reporting)
- performance (response time, throughput, dynamic capacity, static capacity, availability)
- flexibility (scalability, extendibility, unparochialness, multiness, multi-lingual, insallability)
- access control (registration, sign in, password recovery, permission schemes)
- commercial (fees/taxes)
Beside business analysts, the approach of requirement patterns also assists a project management team by allowing them to provide better estimates. It also helps project managers to focus their attention on the most important components during requirements review procedure.
One of the most important applications of requirement patterns, however, is increasing the efficiency of communication within the team. Requirement patterns provide a standard approach for delivering requirements to developers, who get used to the format. They also simplify communications with the client, helping them to understand better what the requirement is.
Occasionally, requirement patterns might steer business analysts away from an obvious way of specifying a requirement and encourage them to approach requirements in a different way. These patterns are derivative patterns. In fact, a requirement pattern may contain any kind of background information, advice, or references to other resources that might be of interest to someone who is mulling over a requirement of this type.
Usage of the approach of requirement patterns results in improving requirement quality, making them more detailed, precise, and clear. It also helps elicit requirements more quickly and with less effort, by taking advantage of the effort already put into the previously developed requirements. As a result, we benefit from the following:
- It is easier to estimate the effort needed to build a specified system.
- Development and testing teams will find it easier to understand the requirements.
- It is easier to share the experience among business analysts within the company.
- Requirement patterns help avoid known mistakes, and lead to standard process, where applicable.