The Value of Requirements
01 February 2018
Although it sounds like common sense we have come to realise that spending time determining and defining the requirements is absolutely critical to the success of a software development project. There are many different tools that can be used and challenges that come with evaluating and handling new tools. So determining the best method takes time and determination.
Our requirements capture process has evolved over time as our team has grown. The main techniques or areas that we cover are;
- System overview
- Sequence diagrams
- Written requirements
- Testing
System overview
Our System overview comprises a flow diagram that identifies each element of a system and how they are connected. This is then supported by high level customer requirements detailing what they require as outputs from the system. An example of these requirements might be the ability for full traceability of all components that are used in a customer’s products. We would also include the high level functions of each element of the system.
The value of documenting these requirements is that everyone involved in the project has a common understanding of the system.
Sequence Diagrams
A sequence diagram shows how elements of a system operate with one another and in what order. We have adapted this principle to fit our needs. Below is a typical sequence diagram.
Each element of our system is defined. With a Web API project they might be Operator, LabVIEW, Web API and Services. Services encompasses all the databases or systems that the Web API will need to interact with. We use Excel to document the elements of the system and then start to build up the functions the Operator will need to perform and how the elements of the system connect to deliver that function. An example of this is shown below;
The yellow boxes define the messages travelling from left to right and the green boxes define the messages travelling from right to left. The URL that is used when a barcode is scanned is defined along with the Service method that is used to perform the analysis of the barcode. On return the details of the messages that are expected and what needs to be displayed to the operator.
The value of documenting this is that each function can be thoroughly designed to minimise rework once development starts. Is it possible to eliminate rework?
Written Requirements
At this point you’re probably itching to develop some code! Written requirements define the detail associated with the sequence diagrams and link the business requirements to the development requirements. An example of a business requirement might be “The operator needs to be able to scan a barcode and the barcode string be available in the system”. This could be translated into a development requirement to create an API that reads the barcode scanner data via a COM port providing initialisation, read and close functions.
The value of written requirements is that it requires the developer to really consider how the business requirement will be implemented. The process of defining developer requirements should be iterative, with the person who writes the business requirements reviewing the developer requirements to confirm they will deliver the required functionality. The written requirements also give a point of reference for how the software should operate.
Testing
Testing and documenting your testing is really important, ideally, the testing that is going to be performed to validate a requirement would be considered when the development requirements are put together. This adds another layer to the design that helps to ensure the functionality will be delivered.
One of the values of documenting testing is that if there are enhancements to any of the requirements, you can return to your test and refine it to meet the enhancement requirements.
One of the biggest challenges with requirements is making sure they are kept up to date as development progresses. We manage this through requirement reviews once development of a particular function is complete.
It would be great to hear about how you manage requirements and if you’d like to come along to our LabVIEW User Group to share your approach, get in touch.
Back to Blog listings