Requirement Reuse: Vision or Realistic?

A systematic list of business requirements is almost never readily available at an analyst’s fingertips. There are certain instances where most of the business or technical requirements are not documents anywhere – it resides in the mind of the stakeholders, the feedback from the end users, and the study from the flowcharts and surveys that yet need to be created. The absolute quality of software products and services depends on the requirements stated in the Software Requirements Specification (SRS). However, several tribulations have been reported in the writing of SRS, e.g. uncertainty, incompleteness and discrepancy, especially when natural language is used.

Managing the dimensions of an ever-growing directory of requirements, test cases and other assets, is a daunting task. Some organizations have indulged into requirements reuse as a way to speed business innovation, reduce risk and control costs. Requirements reuse has been proposed as a key asset for requirement engineers to proficiently draw out, authenticate and document software requirements and as a result, obtain SRS of better quality through more effective engineering processes. The reuse of artifacts of past software development efforts in future ones is a key issue in software engineering. Software reuse is the process of reusing existing software artifacts in building a new system rather than starting development totally from scratch.

In software development life cycle, reusability can be introduced at different phases in the software development life cycle, from requirements to design, to deployment, and at different granularity from subroutine libraries to frameworks to application servers. Patterns could be considered as one of the possible techniques to attain requirement reuse .Basically patterns describe problems that occur over and over again, and then describe the core of the solution to these problems.

Dimensions of Requirement Reuse

• Extent of reuse
  The first aspect has to deal with the magnitude of material that you are reusing. You might reuse just a single functional requirement, or you might reuse a functional requirement along with any associated attributes, such as its rationale, origin, priority, and more if those are relevant to the target project.
• Extent of modification
  The next aspect to consider is how much alteration will be desirable to make existing requirements reusable on a new project.
• Reuse mechanism
  The most rudimentary form of reuse is simply a copy and paste of a piece of requirements information from another specification or from a library of reusable requirements.

Example of requirement reuse - Flight Check-in System

Suppose one has to fly somewhere, there would be a list of activities to be performed. Such as

1. Print boarding passes
2. Change seats
3. Upgrade tickets
4. Pay for checked luggage

Now this could be performed in 3 different ways, in case of an airline website it would enable us to check in, change seats, upgrade tickets and pay for the luggage all together.

The same could even be performed using a mobile device or a self- service Kiosks in a similar way, but having a different mechanism.

It could also be directly performed at an airline booking counter with the airline agents’ help.

The functionality for all these operations would be nearly identical and hence reusable across the three systems, even though the user experience would be different for them. In an ideal scenario we can use the whole package of requirements in multiple projects.  We can use requirements across multiple projects even if the implementation varies in different environments. In various projects the design and functionality could be different, but the requirements could be reused and various versions could be created.

 In Figure 1 we can see that there are 3 projects – Project A, B and C. The initial requirement that was required in case of project A is now being used for project B. It could be used exactly in the same way or minor modifications could be made. Thus there are various versions based on the modifications. In case of the flight check- in system, the functionality might differ but the requirements remain the same.

Figure 1: How a requirement can evolve through reuse in multiple projects

Is Requirements Reuse Right For Your Organization?

Basically requirements reuse is not suitable for everyone; there is a broad continuum of need in terms of requirements management tooling in the market today. It is essential for organizations to first know where they lie on the requirements maturity curve. The requirements maturity curve is not really a curve but it is a dimension of the existing procedure and tools used and/or desired within an organization when it comes to requirements management. As organizations evolve along the maturity curve, the need for more capabilities – such as change management, process and workflow, traceability, reuse, etc. – within their requirements management framework exists. Many companies are still in the early years of requirements management, they have not yet adopted a requirements management tool, and are presently using business productivity applications such as Microsoft Word or Microsoft Excel to capture and track requirements.

Nevertheless, if an association has progressed on the maturity curve with respect to requirements management, and is managing multiple projects and thousands of requirements in parallel and seeking to reduce intricacy, lower cost of development, and abbreviate innovation cycles, then requirements reuse is a concept that should be investigated. Regardless of where an organization falls on the curve, reuse in its most fundamental form will provide a boost to productivity. Rather than re-writing requirements it’s advisable to copy them and modify them for the needs of each project.

Here is a list of sample questions an organization can pose to determine if reuse is a concept that could be leveraged and if it is, which flavor of reuse is best suited to the need.

• How do you identify if you have captured all the requirements from your customer and the business? (Authoring)
• How do your project teams influence work done by other projects? (Reuse)
• How do you authenticate that each and every change made to software systems track directly to its business requirement? (Traceability)
• How do product variations get tracked? (Reuse)
• How do you assess the impact of changed requirements on development schedules and resourcing? (Impact Analysis)
• Can you assess the effect on other projects sharing and/or reusing these requirements? (Reuse)

It is essential to determine the business significance linked with solving these challenges and what precedence do these solutions have within the organization. Reuse may not be part of the short term strategy but successful strategic companies invest in the future and that means a process and a tool structure that will grow with the organization as it matures over time.

By the application of change and configuration management paradigms onto the requirements management discipline in a solitary integrated and traceable solution can carry the power of reuse to a new level. By incorporating a progression on top of reuse and scheming how and when requirements can be tailored and reused enables one to reap these benefits without gratuitously branching and versioning objects unless it is authorized and suitable to do so.

About Author:

Gurpreet Kaur Gaga is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at: gurpreetkaur.gaga@spluspl.com