The Deversus Blog

Requirements engineering is the first and most critical phase in the development of custom software. During this phase, we take an in-depth look at your current business processes and how we can address problems or bottlenecks with a custom built solution. This phase is absolutely critical to the current and future success of the software; without it we are building a house without a blueprint. The only way to validate the success of a custom software endeavour is to understand what needs to be delivered. Thus, without understanding the requirements, we can never hope to deliver a successful system that our clients would be happy with.

There are numerous benefits that arise from an in-depth requirements analysis. Some include:

• Great understanding of development time, and therefore cost. Based on past development experience, we are able to take a brief look at a proposed system and generate a ball-park estimate. After completing the Requirements Engineering phase, we are able to improve from ball-park range to eye of the needle, where we will agree to a fixed price quote for your software.

• Our development team gains invaluable insight into the software they will deliver. The understanding our team gains while spending time with the end users will dramatically reduce the development effort, saving our clients’ money.

• Prioritization of requirements allows for the delivery of a usable system in the most time and cost effective manner possible. We work closely with our clients to place requirements in priority order before we begin development. Since software is constantly evolving the ‘should-have’ and ‘nice-to-have’ features can be planned for and added after a working system is in place.

Take a look at our requirements engineering process outlined below. You will learn about the each phase of the process and discover the deliverables produced at the end of this important phase. Comments and suggestions are greatly appreciated.

Requirements engineering is the first and most critical phase in the development of custom software. This process encompasses all tasks involved in eliciting, analyzing, specifying and validating requirements. The ultimate goal is to generate a set of requirements which can be used by the software development team to build the necessary software. This phase can be broken up into four related sub-phases.

1. Requirements Elicitation

This is the process by which users of the system are interviewed in order to reveal and understand their requirements. This sub-phase involves a high level of client input.

2. Requirements Analysis

This is the process by which elicited requirements are evaluated for consistency, similarity and scope coverage. Requirements are triaged; that is, placed in 3 separate categories:

a) Must-have
b) Should-have
c) Nice-to-have

Through this process the most relevant, mission critical requirements are emphasized and developed first. This ensures the final product satisfies all of the important requirements, and does so in the most time and cost efficient manner possible. Other “should-have” and “nice-to-have” requirements can be relegated to future phases, should they be necessary. Once triaged, the requirements are divided into phases and milestones, which will be mapped to the project estimation and timeline (see next paragraph). For example, Phase 2 may consist of implementing every “must-have” feature. A milestone within that phase may consist of implementing Use Case x, y and z (See ‘Use Case document’ below for the definition of a Use Case). By scheduling the project in this iterative way, our client has a good understanding of when certain things will be delivered and when their input will be required. Additionally, features are generally developed in a “vertical” fashion; once Use Case x has been developed, its unabridged functionality can be demonstrated to the client. In this way, our client has a clear understanding of where development time is being spent, and potential issues can be caught early and dealt with efficiently.

3. Requirements Specification

This is the process by which requirements and their analyses are committed to some formal media. For this project, we would generate four documents during this sub-phase:

a) Use Case document: a use case is a description of the system’s response as a result of a specific request from a user. Each use case will cover certain requirements discovered during elicitation and analysis. For example, a use case may cover “Adding a New Employee”, or “Generating Site Report”. User interface requirements are completely ignored at this point; the goal of the use case is to document system behavior at a high level. Thus, the use case document is simply a collection of logically ordered use cases that will encompass all currently discovered functionality.

b) Interface prototypes: an interface prototype is a rough representation of certain critical functionality, recorded as anything from a hand-drawn image to an elaborate HTML mock-up. The prototypes are completely horizontal in nature; they roughly illustrate how the interface for a certain feature will look and what information is accessible but they will have no back end (vertical) functionality. This will allow us to design a system whereby the important functionality is easy to access and use. Additionally, these prototypes tie in heavily with the triaging process; since screen real estate is of utmost importance when presenting information, by knowing which data and functionality is most important it can receive the most attention.

c) Architecture Diagram: an architecture diagram will be generated for developer use as it is a high level view of how the software will be structured. Only if we feel it will help in our understanding of the system will this document be created.

d) Database Diagram: as with the architecture diagram, a database diagram is generally created for developer use. Through these final two media, we are beginning the shift from words (requirements) to code (software). By generating these two documents we can effectively explore different ways of satisfying the requirements through the software and achieve a more technical understanding of how we will proceed once the development begins.

4. Requirements Validation

This is the final phase of the requirements engineering process. It involves scrutinizing the documents generated during the specification sub-phase and ensuring their relevance and validity. This must be done by all interested parties (which may include the users of the system, financiers of the system and Deversus as the developer) so they are in agreement with the proposed system’s behavior, especially in the case of the Use Case document and prototypes.

Project Estimation and Timeline

As requirements are elicited, analyzed, specified and validated, we will be estimating most features. This is an on-going process that will culminate in the delivery of the Project Estimation and Timeline document. This will outline the duration of work required to develop and deliver Phase 2. As indicated in the Requirements Analysis sub-phase, Phase 2 will likely consist of the majority of the “must-have” features; however it is ultimately up to the client to decide what is most important (even within the “must-have” category), and this will be developed first.

Conclusion

Though the aforementioned processes are part of “Phase 1″ of our software development lifecycle, realize that this process is always occurring. It would be unrealistic to think that everything required from the software can be uncovered during the first phase. Constantly re-analyzing our requirements documents throughout the development process will ensure the risks associated with change are caught early and thus mitigated. Therefore, we can be sure that the Use Case document, for example, will be a “work in progress” piece that is constantly refined throughout the development lifecycle.

The first phase of the software development lifecycle as outlined here is absolutely crucial. In order to build any system correctly and effectively, its purpose must first be established. By carefully defining the requirements of the software at this stage, we can ensure the delivery of a solution that streamlines operations, lowers costs, and provides lasting value.