Devoxx UK 2024 - Going serverless with Quarkus, GraalVM native images and AWS...
A Basic Introduction to Creating a Software Requirements Specification
1. 1/10
March 18, 2021
A Basic Introduction to Creating a Software
Requirements Specification
process.st/software-requirements-specification
Leks Drakos
March 18, 2021
Kamelia Stone is Content Manager at Marketbusinessnews. She likes to travel, meditate,
and draw inspiration from different sources, primarily from books.
Software Requirements Specifications (SRSs) document describes the various software
features, capabilities, coding tests, and functions that are to be implemented in the product.
These parameters also include characteristics, design details, and implementation obstacles
for the development team. The structure of SRS can be modified, depending on the project,
and various features/functions can be added during the process.
SRS lies in the initial, bottom stage of the entire development process. The next stages
include user requirements, which detail the needs of end-users, and describing beyond the
goal of the final product (business requirements).
2. 2/10
No matter how the SRS structure is shifted during the development process, functional
(if/then, data handling, etc.) and non-functional (usability, scalability, etc.) requirements
always take place.
This post for Process Street will discuss:
Now let’s get straight to business.
Choosing a development model: Waterfall or Agile?
Depending on your objective, there are numerous software development methodologies to
choose from. However, two of the most common – and the two this post will focus on – are
the Waterfall and Agile methodologies.
Both methods have a lot to offer and enable your team to deliver high-quality software.
Waterfall tends to be a more predictable methodology, while Agile offers more flexibility
during the development process. Before beginning the development process, it’s important to
determine which method will best suit your needs.
Waterfall Software Development
The Waterfall model is the standard development model where all development stages are
carried out sequentially – the next stage begins after the full completion of the previous one.
Although a high pace is something that’s mostly not associated with the Waterfall model, it’s
still the best for less experienced dev teams. Waterfall provides more time for writing SRSs.
Thus, if your business needs detailed requirements that will remain unchangeable in the near
future, Waterfall is a great option.
The Waterfall model includes the following steps in the software development process:
Requirements identification
Concept
Inception
Testing
Construction
Release
Production
Support
The first step is to do an agile approach defining the technical parameters of the future
program. After that, the team needs to confirm the list of requirements for the software. Then
comes the сoncept stage, where the dev team studies all documentation created to explain the
plan and creation of a Requirements Realization Viewpoint.
3. 3/10
(Source)
Once the concept stage is complete, the dev team performs the inception of the project,
where all the components of the project are integrated.
Only after these stages are fully completed is the final product tested and debugged. Then
follows the implementation (construction) stage, release, production, and support (including
bug fixes and new functionality integration).
Thus, all the stages of software development using the Waterfall model are carried out strictly
sequentially. There is no going back to the previous stage just as there is no stage
skipping/overlapping.
The main advantages of the Waterfall approach are:
Clear documentation of the process;
Accurate budget and deadline definition;
Low dependency on the human factor.
The main disadvantages of the Waterfall approach are:
Long timeframes from project start to the first result;
A large volume of documents;
Continuous coordination of requirements and intermediate documents;
Inability to make dynamic changes.
Agile Software Development
4. 4/10
Agile development methodologies involve collaboration between customer representatives
and developers. Based on an iterative approach, it involves the dynamic formation of
requirements and their implementation within short steps.
The Agile approach implies repeated user feedback collection and implementation of
modifications to the SRS structure performed by a business analyst (BA) every two weeks or
every month. This is needed for proper software development e.g. in the module-by-module
method; once the development team finishes one module, a BA should perform an
acceptance test to verify the module meets all the requirements.
The result of each stage, including the iteration cycle, is a certain miniature software project.
(Source)
There are several methods of Agile software development. The most famous are Scrum,
Extreme Programming, DSDM, Incremental, and Evolutionary strategy.
The Agile principles of software development include the following 12 important points:
Customer satisfaction through rapid and uninterrupted delivery of required software;
Acceptance of changes in requirements even at the end of the development process
(this can increase the competitiveness of the resulting product);
Frequent delivery of working software (every month/week, or even more often);
Close, daily communication between the customer and the dev team throughout the
entire project;
The project is managed by motivated experts, provided with decent working conditions,
support, and trust;
Personal (face-to-face) conversation is the recommended method of communicating
information;
5. 5/10
Working software is the best measure of progress;
Sponsors, devs, and users should be able to maintain a steady pace indefinitely;
Constant attention to improving technical craftsmanship and user-friendly design;
Simplicity is the art of avoiding unnecessary work;
The best technical requirements, design, and architecture come from a self-organized
team;
Constant adaptation to changing circumstances.
The main advantages of Agile software development:
Minimal risk;
Gradual product functionality increase;
Low documentation scopes;
Basic version launch in the shortest possible time.
There are also disadvantages:
Impossibility to determine the exact budget of the project;
Impossibility to determine the exact completion dates;
Not suitable for gov and budget organizations;
Requires motivation from the responsible customer representatives.
Methods of Agile software development
Scrum:
Scrum is a sprint-based method when the working product version must be ready in a month
or sooner (starting from 1 week). In Scrum, tasks are added to Jira right away, which can
help you configure requirements, simplify the test case traceability process, and also adds
sharing, viewing, and commenting features.
There’s no BA to explain details to the team, and a product owner is focused solely on the
long-term project. Scrum is usually a good option for skilled development teams that know
exactly what to do.
Extreme Programming (XP):
XP is an Agile approach that implies interacting with the client at every stage. Thanks to XP,
shortcomings of the previous stages and the required functionality of the product, along with
other parameters, are identified.
DSDM:
DSDM is an iterative and incremental approach and sub-method of Agile software
development that emphasizes sustained user/consumer participation in the process.
6. 6/10
Incremental approach:
Incremental approach is one of the first models of Agile software development. This strategy
is based on the full definition of all requirements for the software tool (system) to be
developed at the beginning of the development process. This approach provides progress
towards the final goal in steps, with each step providing a part of the overall functionality of
the project. This is the way Aurélien Amacker, a French blogger, developed Systeme, the best
tool to create an online business.
The parts (sub-projects) get prioritized, and each of them, in certain cases, is developed
according to its own mini V-model. The most basic functions are implemented (minimum
functionality), which then will be expanded with new ones. The main advantage of the
approach is that you always have a working system. The main disadvantage is the need to
redesign and rewrite the source code when the functionality of the system expands
excessively.
Evolutionary strategy:
Evolutionary strategy is based on partially defining the requirements of the software
tool/system to be developed at the beginning of the development process. The requirements
are gradually refined in successive development cycles. The result of each development cycle
is usually the next version of the software tool or system to be delivered. As with the
Incremental approach, the evolutionary strategy often uses prototyping. In this case, the
main goal is to provide a complete understanding of the requirements.
Key attributes for composing a strong SRS
Here are the main practices you need to follow to create a perfect SRS:
Visualize ּ
Using diagrams, schemes, and models is always a smart move to enrich your SRS. This will
contribute to a better understanding of the processes. Visuals are irreplaceable when it comes
to representing major functions and their connectivity.
Avoid ambiguous language ף
Everything should be clear to avoid endless discussions or useless thoughts and ideas.
Remember, filling in the blanks is not something your development team should do. You
don’t want them to get “creative”. Ambiguous language may often cause confusion, which
means it’s best to avoid subject adverbs (e.g. reasonably, mainly, approximately, etc.),
synonyms, and slash-combined words (e.g. delivery/fulfillment team).
Focus on customers ĝ
7. 7/10
After conducting the necessary field research and comprehensive user interviews, you are
supposed to have a perfect portrait of your end-user. You can even analyze how users are
interacting with you on different channels, especially on social media. You can directly
interact with users on social media and utilize that information to improvise your product at
regular intervals. This information will help you get an idea of all operations your end-users
are going to perform with the product
(Source)
Critical thinking ҭ
There’s a huge number of SRS templates, thus a BA can sometimes get confused with what
information to include in the document. This is where embracing the mindset of a critical
thinker might help. Explain why this requirement has to be implemented and don’t stop
questioning yourself about the priorities. Each requirement comes with a timing aspect that
helps prioritize it.
High priority is assigned to near-term SRSs describing the core functionality of the product,
midterms have medium priority, and so on. While hypothetical requirements are low
priority, they are still important when it comes to getting a whole picture.
Flexibility ԧ
Your SRS must be flexible. BAs watch how it all works, get user feedback, analyze the
outcome, and modify the requirement if needed.
Traceability ԍ
8. 8/10
An ID is assigned to each requirement so that it can be easily tracked in the documentation.
Keep in mind that when reading SRS, a development team needs more context, which means
that it’s highly important to crosslink the project documents with them. However, don’t
forget that hyperlinks can go bad in case document folder hierarchy changes.
History of changes ӝ
Save it. The dev team will then be able to track down each requirement to its original, check
every step and who made it, when, and why. This can help avoid any misunderstandings in
the future.
Definition dictionary Ӗ
Don’t forget to clarify the terms you’re using in the SRS. You can link some of them to the
outside resources and explain those you’ve come up with yourself.
UTools to simplify software requirements specification management
Apart from Jira, you can also use Perforce Helix RM, which is a useful tool and a stand-alone
module in Perforce’s App Lifecycle Management suite.
Helix RM is typically used by large development teams to track metrics such as:
Requirements;
Improve scalability;
Design features (has graphical tools);
Provide real-time collaboration;
Implement test case management;
Create recovery strategies (includes impact analysis tools);
File history graphs.
Helix Rm can also be integrated with Jira, GitHub, Microsoft apps, Slack, Eclipse, Go2Group,
Rational DOORS, and OpsHub.
If you need something more directional, you can also try Pearls to create a requirements
specifications document with just one click. It has impressive team collaboration features
(e.g. comments, activity notifications, features that help define project goals, etc.).
Last but not least, you can use Reqchecker, a tool that will help you check requirements
coverage. This is an additional assurance level that will help ensure all tests and
requirements are covered. Reqchecker can work with Word, PDF, Excel, PowerPoint, and
XML files; feed them to the program, and it will turn them into requirements.
A final word on the software development process
9. 9/10
Each of the approaches discussed above has a certain set of characteristics and is suitable for
projects of different orientations.
Both Agile and Waterfall approaches will help create almost any product. However, the trick
is to determine the one that will implement the project in the most efficient and high-quality
way. If you’re working on a universal project, make sure to consider time, budget, team
qualification, and other criteria you find important.
The Agile approach requires a high level of professionalism from the team and is ideal for
start-ups and advanced niches. The Waterfall approach is most often used in construction,
investment, etc.
(Source)
When choosing an approach, examine their strengths and weak spots, consider expert advice,
and determine a set of requirements for the project. The choice will then be much easier.
Some developers believe that one project can optimally combine Agile and Waterfall
approaches.
Remember that when making a decision in favor of one or another method, the main goal is
to create a quality project that will be able to solve any set tasks.
Development teams are constantly discovering better methods of software development by
developing independently and helping others to do so.
Make sure to remember:
People and interaction are more important than processes and tools.
A working product is more important than comprehensive documentation.
10. 10/10
Cooperation with customers is more important than contract negotiations.
Agility and flexibility are more important than sticking to the initial plan.
Whichever method you choose, keep in mind that while it is vital to keep in mind when
viewing the above statements that being less important does not necessarily mean something
is less valuable.