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).
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:
- Choosing a development model: Waterfall or Agile?
- Key attributes for composing a strong SRS
- Tools to simplify software requirements specification management
- A final word on the software development process
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.
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
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.
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;
- 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.
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 
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
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 
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
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.
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.
- 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.
Which method do you use most in your software development? Share your thoughts on SRS documentation in the comments!
The post A Basic Introduction to Creating a Software Requirements Specification first appeared on Process Street | Checklist, Workflow and SOP Software.
0 Commentaires