As we all know, Devil is in the detail. When it comes to buying software development outsourcing services, the provider’s meticulous approach and attention to the tiniest detail is crucial to your project success. It’s also a great way to check if you’ve chosen the right software development partner – if it fails to gather from you as many details pertaining to your future software product as possible, better run away before paying your first invoice! How your outsourcing partner treats your project specification and requirements will dictate how your project will be executed and what outcome you’ll get at the end of your engagement. So before even doing research on potential providers, make sure to create a technical requirements specification to facilitate project estimation and deliveries roadmap. Insufficient requirements will have drastic effects on your project development and software engineering down the road, including:
- Misunderstandings with your service provider regarding the project scope;
- The wrong choice of technology, architecture or team management methodology;
- Rapid change of priorities resulting in your development team being frustrated and losing focus;
- Security gaps;
- Overheads related to change requests in case of a fixed price business model;
- Numerous product pivots and strategic changes resulting in extra payments and high staff attrition, etc.
As a custom software development client, it’s in your power to protect yourself and your project development team from these kinds of mishaps. Plan beforehand, define time you need to spend on putting together the requirements documentation, and take time to discuss it with your service provider. It’s recommended that you have at least two face-to-face meetings/conference calls with your development partner for requirements discussion. At 8allocate, we usually offer our clients (who engage via fixed price and T&M models) to have an extended Discovery workshop, which allows us to interview the Product Owner and other stakeholders, gather requirements from them, then do target audience and market research and make our own suggestions about what requirements are missing and should be added to make sure the product completely resonates with target users’ expectations.
There are a couple of requirement types that you need to keep in mind when planning your software dev project.
The high-level requirements include:
- Business requirements (e.g. business goals, objectives and needs);
- User requirements (what the user needs the product to do);
- System requirements (functional and non-functional ones).
The lower-level requirements include, but aren’t limited to:
- Stakeholder requirements;
- UI requirements;
- Market requirements;
- Implementation/transition requirements, etc.
Now let’s delve deep into functional and non-functional requirements.
Functional requirements
Functional requirements provide a very detailed description of all of the functions your future product will have, how it should behave, and how it should respond to different user commands and gestures.
The functional requirements are mostly about how the system should act when the user interacts with it. How the login process should look like, what kind of information the user will be able to retrieve/have access to with what type of membership, what the user journey will be like, etc.
While there are different ways to include functional specifications into your business requirement document, one of the most popular ways is just by plain text. It is also common to draw a diagram to visually show the relationships between the user and the system but this approach has its drawbacks: it’s easy to misunderstand the issue or omit the context of the situation.
Use Cases
In the past, people used to describe the system functionality by describing separate functions and features. However, in the mid-90s Ivar Jacobson proposed what he called Use Case as a new way to describe the functionality of a product.
When you describe requirements not as separate functions, but as a whole while considering the current context and simulating how users will interact with the entire system, you have a better chance to ensure the completeness and non-redundancy of requirements.
A regular use case should include:
- Actors – Users that interact with a system.
- System – The system that is built according to the specifications.
- Goals – What makes user interact with a system and what they want to achieve as a final result.
As we describe context with the help of use cases, we also need to include the following complimentary sections that would give us all relevant information:
- Description
- Pre- and post-interaction condition
- Basic interaction path
- Alternative path
- Exception path
Use cases are easy to understand by both technical and non-technical people and can be used for making test cases. It gives your software development provider an ability to link your initial client requirement (business language) with the technical requirements (programming language).
Another important role that use cases play is they let you better understand your product users’ logic. By prioritising use cases you come better specify your user interface (UI) design. Also, by identifying the frequency of user actions within the system described in use case, you will be able to better specify the requirements for your system performance.
User Story
Another way to structure functional requirements is by writing them in the form of user stories. User stories tend to better emphasize the end user and their goals. The typical structure of a user story looks as follows:
As a type of user, I want some goal so that some reason.
For example: As a user I want to have my Google account connected to my profile so that I will be able to log in with the Google account.
Every user story should be accompanied by the acceptance criteria that define the conditions the feature should meet/satisfy in order to be accepted by your product owner and stakeholders. One user story should have at least one acceptance criterion, each being testable and transparent to all of the stakeholders.
For example, the acceptance criteria for a login feature might be as follows:
- User can use an email or a mobile phone number to log in;
- The lengths of the password should be between 6 and 20 symbols;
- Symbols in a password may include letters, numbers and special signs.
Without acceptance criteria, it will be very hard for you to identify whether you’ve planned a right feature to be built and how it complies with your initial idea/vision.
There is no one-size-fits-all solution when it comes to functional requirements tracking. Choose the method your team is more comfortable working with and at the same time the one that gives you the complete understanding of how your product features should look like.
Non-functional requirements
At the same time, non-functional requirements define how your system must work. Some of the non-functional requirements include:
Usability requirements
It defines how easy or difficult it is for the user to learn and use the product. It can be defined by tracking the number of errors the user has had while interacting with a system, and the number of tasks the user has done by themselves without any additional help. Also, usability defines how intuitive your app’s design is for the user, whether it’s easy or not to find the right button to click and the right feature to use.
Usability requirements may also include the localization details and the use of languages.
Performance requirements
It describes how the system responds to the user actions. For instance, this requirement may include load time for a particular page or mobile responsiveness.
Availability requirements
When writing down availability requirements, you should mention the part of your system that needs to be available for user at all times. In case of unexpected system crash and its temporary unavailability the user should be notified by a message explaining the problem and telling the user when it’ll be fixed.
Scalability requirements
Scalability requirement defines what should be done so that the system will be scaled properly and without downtime. That means you should define how many users, transactions, payments, etc. your system will be able to process.
Security requirements
Security requirements define the levels of access to the system and make sure that the system is protected from an unauthorized access. It can also include the frequency of security testing and the compliances the product should cover to be able to function within a particular jurisdiction (e.g., PCI DSS, HIPAA, GDPR, etc).
There is a long list of different types of requirements you can mention before hiring a project development partner. My advice would be to take time before diving deep into the development process to figure out all of the smallest functional and non-functional requirements, and to share them with your development partner to make sure they build and deliver a truly meaningful product with the right set of features able to fulfill your business mission by 100%. And never accept anything less than you deserve!
