Tag Archive for: SRS Document

Requirements Analysis

Requirements analysis is a critical part of the requirements definition and management process in software development. The purpose of requirements analysis is to be sure all product requirements accurately represent stakeholder needs and requirements. When executed correctly, requirements analysis results in a set of product requirements that, when met, will result in a deliverable that matches stakeholder expectations.

What is requirements analysis?

The requirements analysis is the process of discovering stakeholder needs and requirements for a software application being developed. It confirms accurate capture, interpretation, and representation of the customers’, users’, and other stakeholder needs and transforming those needs into a set of requirements for a product. For optimal results, the set of product requirements must be verified that they have the characteristics of well-formed requirements (e.g. needed, unambiguous, complete, consistent, correct, feasible, verifiable) and validated that they represent the intent of the needs from which they were transformed.

Best practices for requirements analysis

Stakeholders can communicate their expectations in several forms – needs and requirements.  The stakeholder needs represent what the stakeholders need the product to do to address the problem or opportunity the product is to address; stakeholder requirements are stakeholder-own product requirements that communicate what the stakeholders require of the product to meet their needs.  Stakeholder needs are expressed in natural language without the use of “shall”, while stakeholder requirements are communicated with “shall” to make sure they are treated as binding requirements the product will be verified to meet.

It is important to define and understand the stakeholder needs and requirements before defining the product requirements to which the product will be designed and built to. Given there are multiple stakeholders, there will be multiple sets of stakeholder needs and requirements.  It is up to the project team to elicit these needs and requirements, resolve conflicts, inconsistencies, and other issues.  The results will be an integrated set of needs from which the product requirements will be transformed.  The resulting product requirements represents what the product must do in order for the needs to be met.  If needs describe the “what,” product requirements define the “how.”

Requirements traceability is of the utmost importance to the requirements analysis process. It is used to ensure that each requirement clearly communicates the intent of their source. Without traceability, it’s nearly impossible to know if the software product meets stakeholder needs, drivers and constraints, goals, and objectives. Requirements analysis could be executed perfectly, but without requirements traceability to their source, there would be no way to prove you have the right set of requirements.

Therefore, a best practice of requirements analysis is to ensure that each requirement is traceable to all corresponding artifacts. These artifacts include not only their source but also downstream artifacts including the design, product verification planning and product validation planning.

Another equally important best practice for requirements analysis is to execute a predetermined process. Carefully performing each step can be the difference between a software product’s success or failure to meet stakeholder needs.

RELATED POST: Requirements Management Tools and Software

The requirements analysis process

Generally, there are seven steps in the requirements analysis process.

  1. Identify stakeholders: the first step is to pinpoint exactly who the key stakeholders are for the project. This includes internal and external customers, users, regulatory agencies, and stakeholder involved in the development of the product. It is the stakeholders that are the source of needs and requirements.
  2. Elicit stakeholder needs and requirements: during this step of the requirements analysis process — also called needs and requirements gathering — teams work with the stakeholders to identify their needs and requirements.
  3. Model needs and requirements: with the initial sets of stakeholder needs and requirements, teams can create visual representations or diagrams of the needs and requirements as part of their analysis to inform the definition of the product requirements, use cases, and user stories. These visual representations and diagrams are used to solicit feedback from stakeholders, iterate, resolve issues, conflicts, and inconsistencies before defining and baselining the product requirements.
  4. Retrospective: the project team reviews the data and information gathered during elicitation, diagraming and modeling. Of particular interest is understanding the drivers and constraints to better understand feasibility and risks associated with developing the product, assess whether anything has been missed and establish a budget and schedule.
  5. Define an integrated set of needs: The project team derives an integrated set of needs that represent the stakeholder expectations along with goals, objectives, and drivers and constraints, and stakeholder requirements.
  6. Define product requirements: at this point, teams review the resulting integrated set of needs and stakeholder requirements and transforms them into a set of requirements for the product to which the product will be designed and built. It is important that the resulting requirements are high-quality requirements having the characteristics of well-formed requirements. It’s wise to make sure that all team members know how to write good requirements.
  7. Sign off and baseline: the final step of the requirements analysis process is to get sign off agreement from all key stakeholders (or representatives from stakeholder groups) identified in step one for the integrated set of needs and resulting set of product requirements. This is a formal contract that lets everyone know what the product will be verified and validated against, the cost, and schedule. It helps eliminate surprises and scope creep later in the development process.

Common challenges during requirements analysis

These steps above will likely need repeating, as the most common challenge of requirements analysis is that requirements may change throughout the software development process. As the team implements various features, the above steps should be repeated for each feature; doing so will often result in additional needs and requirements. The risk of change can be reduced by following the above steps and getting sign off at the beginning of the project for not only the integrated product but for each feature to be provided by the software application.

One reason for change is a failure to include all relevant stakeholders. If the focus is just on the customers or users, needs and requirements associated with other stakeholders will be missed. Given the number of different stakeholders, there will be inconsistencies, conflicts, and issues. Failure to deal with these early, will result in change. The use of various visualizations, diagrams, and models before defining the integrated set of needs and product requirements helps ensure completeness, correctness, and consistency. Again, failing to do this before defining the set of product requirements will result in change and resulting costly and time-consuming rework.

In other situations, it may be that some stakeholders won’t know exactly what they need until they see the software in action, or project constraints may necessitate changes in the solution. In any case, agile teams are constantly iterating and updating design. This means the process of evaluating needs and requirements almost never ends. The diagraming and modeling step above is a great tool that can be used to interact with the stakeholders to better understand their needs. The goal is to be as comprehensive as possible the first time through to get a big-picture view to minimize change and resulting rework.

The pros and cons of various diagraming and modeling techniques

A variety of techniques are available during elicitation, diagraming, and modeling—some are more advantageous than others. Here we review some popular techniques and point out advantages and disadvantages of each.

Flowcharts 

Flowcharts show the sequential flow and control logic of a set of related activities, and can be used to represent data flows, system (software application) interactions, both internally and externally, and more.

PRO

  • Multiple formats: linear, cross-functional, top-down.
  • Easy to create and understand for all team members.
  • Highlights critical process attributes.

CON

  • Change management is time consuming, as flowcharts need to be redrawn to accommodate process alterations.
  • Complex processes result in dense flowcharts that can be difficult to understand.

Data flow diagrams

These show the flow of information through a system. Data flow diagram components include the process, flow, store, and terminator.

PRO

  • Can be created in the requirement elicitation step of the analysis process to define a project’s scope.
  • They can be understood by technical and nontechnical audiences.

CON

  • It can be time consuming to create, particularly for complex software applications.
  • Physical considerations are not included in a data flow diagram.

Role activity diagrams

Role-activity diagrams show business and software processes as a progression of actions conducted by role. Roles are identified by activities and grouped into responsibilities. They can be used for describing use cases, workflows, business processes, or software protocol.

PRO

  • Illustrate the individual steps in activities, as well as the order in which they are to be performed.
  • Supports communication across roles.

CON

  • Each workflow requires a new diagram else they become too unwieldy. This makes it difficult to get a full view of the system.
  • These diagrams do not provide detail about how objects behave or collaborate.

RELATED POST: Nonfunctional Requirements vs. Functional Requirements – What’s the difference? 

Unified Modeling Language (UML)

Unified Modeling Language creates diagrams used for modeling specification, development, visualization, and documenting in the requirements analysis process. UML diagrams can be two types of models: a behavioral model, which informs on what the software application will do, and a structural model, which provides insight on the parts that make up the system.

PRO

  • There are a variety of UML diagrams to choose from, like use case, sequence, interaction, class, and more.
  • Can be directly inputted to a requirements tool.

CON

  • UML diagrams must be synchronized with software code, which requires additional work and ongoing maintenance.
  • Complex processes result in overcomplicated and confusing diagrams.

Business process modeling and notation (BPMN)

BPMN is based on a flowchart technique like activity diagrams from Unified Modeling Language (UML). It uses a unique standard of notation to create graphs including flow objects, connecting objects, swim lanes, and artifacts. These help simplify understanding of the business process answering questions regarding who performs the activities and the data elements required to do so.

PRO

  • Designed to be understood by all business stakeholders yet represent complex process semantics.
  • Supported by most modeling tools.

CON

  • Only supports concepts of modeling applicable to business processes; non-process purposes are out of scope.

Gantt Charts

In requirements analysis, Gantt charts help with coordinating, planning, and tracking project tasks. Tasks to be performed are listed along the vertical axis. The horizontal axis lists the time allotted for the given task and the person or team performing the functions. Gantt charts give a visual representation of the project’s schedule and resources needed.

PRO

  • A single chart can track many activities, even those happening in parallel.
  • It provides a realistic view of how long the project will take and what resources are needed at various points in development.

CON

  • A single view of all the tasks is not available.
  • The time allotted for a task is not representative of the amount of work involved in its completion.
  • Complex software projects would require an exorbitant number of tasks making the Gantt chart extremely difficult to create and nearly impossible to update consistently.

Integrated definition for function modeling (IDEF) diagrams

IDEF is a family of modeling languages that cover a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design, and knowledge acquisition.[i] The goal is to gain an understanding of an organization’s systems by exploring process function relationships to child/parent systems.

PRO

  • IDEF can be used in almost any context, industry, and technology area.
  • Diagrams are easy to digest for both technical and nontechnical team members.

CON

  • It can be difficult to integrate different IDEF techniques.
  • Designed as a business analysis tool, it is not a very good software application development methodology.

Gap analysis

Also known as need analysis, need assessment, or need-gap analysis, this technique helps analyze software application performance gaps to verify if business requirements are successfully met. Gap analysis conveys the difference between the current state and the target state, identifying where the project stands and what is yet to be done.

PRO

  • Gap analysis ensure the business requirements or data requirements have been met as desired.
  • It helps uncover which areas need focus or additional resources.

CON

  • Success depends on the skills of those performing the analysis, and while gaps may be uncovered, their true causes may be left unsolved.

Focus of the various diagraming and modeling techniques

Some requirements diagraming and modeling techniques are better for analyzing business needs and requirements while others are better suited for discovering user needs and requirements.

BPMN is strictly a technique for uncovering business needs and requirements which must be addressed within the set of product requirements, with excellent results. Gap analysis is also great method for understanding business requirements. As noted, it can help determine the difference between where a business is and where it wants to be. The result may initiate a series of user requirements to help the business close that gap.

While not covered above, a customer journey map is also beneficial for discovering business requirements. A customer journey map is a “voice-of-the-customer” VOC story that shows the customer’s relationship with the business over time. It helps identify sources of frustration on the part of the customer, which can inform user requirements to improve those pain points.  Note: limiting this analysis to just a single class of stakeholders can result in missing needs and requirements.  A more inclusive approach is “voice-of-the-stakeholders” VOX that shows relationship of all relevant stakeholders with the business over time. It helps identify sources of frustration on the part of all stakeholders, not just the customer, which can inform the definition product requirements to improve those pain points.

The discovery of user needs and requirements benefit from techniques like the data flow diagram. As mentioned, they can be created early and give a high-level of the data flow within a particular process. Use cases and user stories are also great tools for soliciting software requirements from a user perspective, as they maintain focus on what the user needs, not what the product does to meet those needs and wants.

Streamlining the requirements analysis process

The result of the requirements analysis phase of requirements definition and management, is the diagrams and models used as part of the analysis, an integrated set of needs, and a set of product requirements that are inputs to the design process.   The set of product requirements  define the features and intended behavior of the software application being created such that when implemented within the design, the stakeholder needs are met. Having a baselined set of product requirements serves to crystalize project specifics and mitigate wasted time and potential rework.

While some organizations will communicate this set of product requirements in a document form (e.g.,  a Software Requirements Specification (SRS)), the increasing trend is to manage the requirements within a requirements management software application.

The reason organizations are moving towards a data-centric practice of product development is that is hard, for any document-based approach to be flexible and scalable enough for complex agile projects. This is especially true for highly regulated industries that must prove compliance. Due to numerous factors—lack of consistent updating, human error, incomplete data, version control, the need to establish and maintain traceability, etc.—documents simply cannot be relied upon determine whether a need or requirement is fulfilled.

Agile product teams working on complex products in highly regulated industries will have much more success using a requirements management software application to streamline the requirements analysis phase of requirements definition and management. Modern requirements definition and management solutions, like Jama Connect®, define, establish traceability, manage, and validate complex product requirements automatically, which simplifies not only requirements analysis, but the overall requirements definition and management process.

With Live Traceability™ and digital thread, Jama Connect helps teams collaborate in real time. This mitigates the risks of using documents for requirements analysis. It also enables traceability automatically so the hard work performed can be proven—even with the most complex, highly regulated software products.

See How Jama Connect streamlines requirements analysis and requirements management.

[i] https://www.idef.com/


SRS Documents

Imagine that you’re in charge of designing a 17-story building—but the blueprints are missing. Moving forward without this essential document would put the entire project at risk for serious errors. Launching a new software project is similar in that without a blueprint, you’ll likely produce a system that lacks the necessary software functionality and isn’t aligned with the customer’s needs. Clear requirements, such as those included in a system requirement specifications (SRS) document, create a foundation that ensures your team delivers the right product and avoids expensive reworks.  

But where should you start? In this article, we’ll explain details about SRS documents and how to use them, and we’ll provide examples to get you on the path to success.  

What is a System Requirements Specification (SRS) Document?  

The SRS document is focused on what the software needs to do and how it must perform. It lays the important groundwork so that every person involved with the project understands the most crucial details.  

An SRS document outlines the behaviors, functions, and capabilities required of the system, along with any potential constraints. Functional and nonfunctional requirements are included. Design suggestions and information outside the customer’s requirements are not included.  

Approval is received from all necessary stakeholders, showing that they clearly understand the project requirements and everyone agrees. In a sense, the SRS document functions as an insurance policy that any party can refer to in case of uncertainty.  

Why Use SRS Documents?

Using an SRS document ensures that specifics around a project are crystal clear, mitigating the risk of wasted time and potential reworks. Important benefits of using this type of document include: 

  • Providing Valuable Customer Feedback. An SRS document is the customer’s confirmation that your organization understands the problems that need to be solved and how the software must behave to address the challenges. Visuals such as charts and tables can provide additional clarity.  
  • Breaking Work Into Smaller Pieces. SRS documents contain a large amount of information, but they ultimately break problems into smaller, more manageable parts.  
  • Serving as a Parent Document. The SRS serves as a parent document to any additional documents that follow its creation. The scope of work, software design specifications and other documents often leverage what is highlighted in the SRS document. Plus, it can serve as a product validation check. Did we do it right? Check the SRS document.  

The SRS document assists with identifying problems earlier in the development process, which helps manage time more effectively. It’s far easier, for example, to update specifications before any development has begun, versus later in the process.  

SRS Document Format: How is a System Requirements Specification Document Written? 

Similar to following a recipe, there are several important components, or ingredients, in an SRS document. A good document needs to answer a few critical questions, such as:

  • What should the software do?
  • How should it behave?
  • What are the performance requirements? 
  • Are there any constraints that need to be noted? And if so, what are they?  

A good starting point is an SRS outline. A rough outline of the various sections can help you get ready to fill in the important details. Consider the following:  

  • Create an Introduction. The introduction addresses what the software needs to do (and what it should not do). The development team and product owners should be involved in writing this part of the plan. Why does the product need to be built? What challenges does it solve? And who is going to use the product? Additionally, the SRS introduction might contain an overview of what is included within the document.  
  • Write a General Description. Focus on the functionality of the product. Define the required hardware and user interfaces. What do end users expect the software to do? What are the various functionalities? Ultimately, this section will focus on system interfaces, user interfaces, hardware interfaces, software interfaces and more. Additionally, any important assumptions need to be included.  
  • Include Specific Requirement Specifications. This section examines specific details about the product so it’s easier to design and validate that it has met requirements. It describes all inputs that the software must handle, highlights any required outcomes and clearly defines any necessary integrations. Performance criteria should also be included, as well as any software system attributes, such as readability, availability, security, profitability and more.  

Once you have the basic outline, you can start filling it out with the help of your team and client. Upon completion, get final approval. Everyone important to the project needs to review and approve the final version of the document.  

Requirement specifications included with the SRS document are diverse, so there isn’t a one-size-fits-all template. However, a general software requirements template such as this one can be used to create the “bones” of your document. You can then fill in the details as you go.  

Software requirements specification document template

What Should Not be Included in a System Requirements Specification Document? 

As you become more experienced at writing SRS documents, the process will become much faster. However, in the beginning, it helps to have a list of common mistakes to avoid. Consider the following:  

  • Failing to Include a Complete Dictionary. Does your SRS document include jargon that only people in a specific industry understand? If so, create a dictionary section for easy viewing and include definitions of any terms not commonly understood. 
  • Creating Confusion by Mixing Concepts. Keep your document organized and be careful to present information to readers in a logical flow. Avoid mixing concepts throughout the document so that you don’t create confusion.
  • Not Fully Understanding the End User. Who will interact with the software, and what are the expected results? For example, imagine that a software is supposed to generate reports. Part of the requirements address how the user will click on a specific button to generate various reports. Ensure that you know what is expected from the report generation software, but also know who is clicking on that button so you better understand the user and the required functionality.  
  • Being Too Ambiguous. Ensure that your requirements don’t lead to unclear interpretation. An SRS document is designed to prevent misunderstanding, so make sure the document doesn’t generate it. For every functionality or situation description, make sure that you don’t present specifications that haven’t been defined yet.  

How Can Software Streamline the Creation of SRS Documents?  

Resources that assist with simplifying requirement specifications are helpful in writing your SRS document. For example, Jama Connect is a hub designed to follow your complete product development life cycle, enabling product managers and engineers to track requirements, decisions, and relationships on multiple levels and deliver compliant, market-driven products effectively.  

Jama Connect helps teams deliver high-quality products on time and on budget by aligning stakeholders, identifying risks early on, and visualizing connections between regulations, requirements, and test cases throughout the development process. If you’re looking for a solution to simplify writing SRS documents, ensure that it provides:  

  • Confidence. Traceability requirements should be apparent throughout the entire development process, illuminating risk and allowing you to proceed with confidence.  
  • Visibility. The solution should offer visibility into the product development process by monitoring relationships and dependencies between systems, teams, activities and results. 
  • Speed. Speedy alignment should be provided, which assists with tracking decisions, increasing efficiency and minimizing reworking to create high-quality products on time and on budget. 
  • Adaptability. Make sure the solution easily adapts to your organization’s workflows, creating an intuitive experience for your teams to get up to speed fast.  
  • Performance. Ensure the system provides benchmarks and monitors team performance over time to better understand the benefits of retooling your product development process.  

Overall, you want to make sure that any software that assists with streamlining the creation of SRS documents equips your team with the ability to analyze impacts, track decisions and ensure the quality of the product you set out to build.  

Moving Forward With Greater Success  

Designing a robust SRS document ensures that you have a “go to” document for your entire development project. The goal is to smooth out any potential implementation snags prior to the program development process. Yet at the same time, the document needs to be flexible and scalable so that it’s easy to modify with product demands.  

Keeping the above tips in mind when writing and reviewing requirements empowers you to create a project that closely aligns with clients’ needs, prevents costly mistakes and ultimately supports you in building better products.