This is the second part of a two-part article on software requirements gathering.
In the first half we discussed:
- Template: the one asset you need
- Diagrams and schemes: use, don’t abuse
- Requirements elicitation: stakeholders and approaches
Now let’s dive into it.
Mockups: an image is worth a thousand words
It is widely recognized that a substantial portion of software defects (up to 85%) originates in the requirements engineering phase of the software development process (1).
The reasons behind this statistic are often: poor, ambiguous, incomplete or unclear specifications. The role of mockups is to help reduce the ambiguity surrounding the written language showing how the system will be designed, implemented and used.
Mockups are drawings that show how the user interface of a subject software system is supposed to look during the interaction between that system and the end-user (user-system interaction). (2)
A study about comprehension effectiveness using mockups has revealed that “ […] a significantly large effect of the presence of screen mockups on the comprehension level. The mean percentage improvement of comprehension level achieved with mockups ranges from 56% to 78%, with an average of 69%.” (2)
So, now that the importance of mockups it’s clear, let’s see how you can use them and what characteristics they have. There are different types of mockups, based on their fidelity to the final product: wireframes, mockups, prototypes.
Wireframes are a bit more detailed than sketches, they need to be designed rapidly to provide quick feedback to the users. They are usually modified multiple times during the initial phase of the software analysis, when clear requirements are scarce. Therefore, wireframes are typically in black and white and lack high-fidelity details.
With the progression of the analysis, generally at the end of it, there should be enough information to design a complete mockup.
Mockups are more detailed than wireframes and comprehend colors. Depending on the number of details included and how close they represent the end result, mockups are defined as hi-fidelity (more detailed) or lo-fidelity (less detailed). In recent years, the need for more clarity has pushed designers to make further efforts toward something with a stronger identity and appeal over the users.
This effort led to interaction design, which adds a strong interactive component to mockups to make them even more hi-fidelity and engaging, therefore clearer. This technique aims to simulate a prototype without the fatigue that comes with creating a real one. In this way, the end-users can click over buttons and links to better understand both processes and user experience.
Finally, prototypes are the most detailed and precise, because they are real applications whose scope is to present an almost-functional end product. In the majority of cases, prototypes have a larger realization cost and require more working time than mockups and wireframes. For this reason, they are usually less used.
Constraints: be clear and provide the right information
Scott W. Ambler, Vice President and Chief Scientist for Disciplined Agile at Project Management Institute, says: “A constraint is a restriction on the degree of freedom you have in providing a solution. Constraints are effectively global requirements, such as limited development resources or a decision by senior management that restricts the way you develop a system.”
Constraints are fundamental for a clear and robust software requirements specification, they provide the conditio sine qua non for a successful product. Their role is to protect both you and the customer, assuring that the final result will match what has been required. There can be several types of constraints: political, hardware related, performance related, economical and others.
What is important is to be very clear with what is absolutely necessary for the software to function as it is expected to. For example, the customer should provide some digital content needed to populate the site’s home page, or maybe it is mandatory to have administration access to a third-party system. Other questions could be: at what time should the system launch a routine, or where should the hardware be installed, are there all the necessary power outlets or network connection cables available? These are crucial factors that will impact the project course, just one missed constraint could be sufficient for the activity to fail entirely.
Here are some more explicit examples:
System constraints limit how the system can operate in a specific context or under known circumstances. Sometimes they also limit design choices related to system functioning. Examples could be hardware limitations, database brands, cloud-native approach, etc.
This type of constraint specifies how the software should function in relation to the users.
Sometimes they can be confused with business needs or requirements, since they are, in fact, very similar.
Examples could be the training time required for a user to learn to use a process productively, the time a specific task needs to be executed or the request to conform to explicit usability standards.
Hardware constraints are perhaps the easiest to understand. They define what it is mandatory for the system to work, for example, the minimum amount of RAM, number of cores, connection cables types, etc.
Operational constraints define how the software should work when run in production. For example minimum number of contemporarily logged in, maximum bugs rate, minimum accepted uptime, etc.
Whatever the constraints should be, always be clear from the beginning and help your customers identify the essential points, which should be checked against technical feasibility before the final kick-off.
Versioning: keep track of every change
Versioning is another vital part of your requirements document.
Assure that every change is registered with a new document version along with dates. You can choose the naming convention strategy you prefer, just be consistent with it in all the documents, for example, v. 1.0 could stand for the first revision, where 1.1 indicate a minor change in specification and 2.0 represents a major change that is going to impact a large function or process. A good practice asks for a changelog to accompanying the new document version, so that changes are easy to recognize and research without the need to confront multiple files or read through them several times. A correct versioning strategy helps avoid misunderstandings between you, the customer and the development team.
One more thing: Progress of work
“Treat your customers like they own you, because they do.” — Mark Cuban
Once the analysis is completed and the project has started everyone’s going to have the same question in mind: When are we going to finish it?
Depending on how long the project lifespan is, the development will be impacted by several changes (that’s why Agile is so popular). These changes are going to influence project costs, time and features. In order to provide punctual feedback and keep a record of every change, it is advisable to compile a document after every meeting or, if there are no meetings in the meantime, at maximum every month.
The document should list all the decisions taken and the changes approved, keeping everyone in the loop and conscious.
You can use the same document, updating it with a new version and date, this way all the project history will be available in a single file which will be shared via email, cloud, or a specific software with no need to identify the correct one each time is needed. The form is not important here, be it a PowerPoint or a Word, what matters is the ability to make all the stakeholders aware of what is changed.
In conclusion, we covered experts’ advice and research about some fundamental aspects of software requirements specification.
This is a wide topic and should require studying and attention, but don’t worry, in the next article I’ll be talking about tools and software that can help you during requirements gathering and writing. Don’t miss it out!
(1) YOUNG, R. 2001. Effective Requirements Practice. Addison-Wesley, Boston, MA
(2) Ricca, Filippo & Scanniello, Giuseppe & Torchiano, Marco & Reggio, Gianna & Astesiano, Egidio. (2014). Assessing the Effect of Screen Mockups on the Comprehension of Functional Requirements. ACM Trans. Softw. Eng. Methodol.. 24. 1:1–1:38. 10.1145/2629457.