Tag Archive for: best practices

How can you distinguish excellent software requirements and software requirements specifications (SRS) from those that could cause problems? In this post, we’ll start by discussing several different characteristics that individual requirements should exhibit. Then, we’ll then look at the desirable traits a successful SRS should have as a whole.

Characteristics of Effective Requirements

In an ideal world, every individual user, business, and functional requirement would exhibit the qualities described in the following sections.

Complete

Each requirement must fully describe the functionality to be delivered. It must contain all the information necessary for the developer to design and implement that bit of functionality. If you know you’re lacking certain information, use TBD (to be determined) as a standard flag to highlight these gaps. Resolve all TBDs in each portion of the requirements before you proceed with construction of that portion.

Nothing says you need to make the entire requirements set complete before construction begins. In most cases, you’ll never achieve that goal. However, projects using iterative or incremental development life cycles should have a complete set of requirements for each iteration.

Using minimal requirements specifications runs the risk of having different people fill in the blanks in different ways, based on different assumptions and decisions. Keep requirements details verbal instead of written also makes it hard for business analysts, developers, and testers to share a common understanding of the requirements set.

RELATED: Move to Jama Connect® — A Modern Requirements Management Alternative to IBM® DOORS®

Correct

Each requirement must accurately describe the functionality to be built.

The reference for correctness is the source of the requirement, such as an actual user or a high-level system requirement. A software requirement that conflicts with its parent system requirement is not correct.

Only user representatives can determine the correctness of user requirements (such as use cases), which is why users or their close surrogates must review the requirements.

Feasible

It must be possible to implement each requirement within the known capabilities and limitations of the system and its operating environment. To avoid specifying unattainable requirements, have a developer work with marketing or the BA throughout the elicitation process.

The developer can provide a reality check on what can and cannot be done technically and what can be done only at excessive cost. Incremental development approaches and proof-of-concept prototypes are ways to evaluate requirement feasibility.

Necessary

Each requirement should document a capability that the stakeholders really need or one that’s required for conformance to an external system requirement or a standard.

Every requirement should originate from a source that has the authority to specify requirements. Trace each requirement back to specific voice-of-the-customer input, such as a use case, a business rule, or some other origin of value.

RELATED: Carnegie Mellon University Software Engineering Program Teaches Modern Software Engineering Using Jama Connect

Prioritized

Assign an implementation priority to each functional requirement, feature, use case, or user story to indicate how essential it is to a particular product release.

If all the requirements are considered equally important, it’s hard for the project manager to respond to budget cuts, schedule overruns, personnel losses, or new requirements added during development. Prioritization is an essential key to successful iterative development.

Unambiguous

All readers of a requirement statement should arrive at a single, consistent interpretation of it, but natural language is highly prone to ambiguity. Write requirements in simple, concise, straightforward language appropriate to the user domain. “Comprehensible” is a requirement quality goal related to “unambiguous”: readers must be able to understand what each requirement is saying. Define all specialized terms and those that might confuse readers in a glossary.

Verifiable

See whether you can devise a few tests or use other verification approaches, such as inspection or demonstration, to determine whether the product properly implements each requirement.

If a requirement isn’t verifiable, determining whether it was correctly implemented becomes a matter of opinion, not objective analysis. Requirements that are incomplete, inconsistent, infeasible, or ambiguous are also unverifiable.

Characteristics of Effective Software Requirements Specifications (SRS)

It’s not enough to have excellent individual requirement statements. Sets of requirements that are collected into a software requirements specification (SRS) ought to exhibit the characteristics described in the following sections.

Complete

No requirements or necessary information should be absent. Missing requirements are hard to spot because they aren’t there! Focusing on user tasks, rather than on system functions, can help you to prevent incompleteness. I don’t know of any way to be absolutely certain that you haven’t missed a requirement. There’s a chapter of my book “Software Requirements, Third Edition” that offers some suggestions about how to see if you’ve overlooked something important.

WRITE BETTER REQUIREMENTS: Jama Connect® Features in Five: Jama Connect Advisor™

Consistent

Consistent software requirements don’t conflict with other requirements of the same type or with higher-level business, system, or user requirements. Disagreements between requirements must be resolved before development can proceed. If you spot a pair of conflicting requirements, you might not know which one (if either) is correct until you do some research. Recording the originator of each requirement lets you know who to talk to if you discover conflicts in your software requirements specification.

Modifiable

You must be able to revise the SRS when necessary and maintain a history of changes made to each requirement. This dictates that each requirement be uniquely labeled and expressed separately from other requirements so that you can refer to it unambiguously.

Each requirement should appear only once in the SRS. It’s easy to generate inconsistencies by changing only one instance of a duplicated requirement. Consider cross-referencing subsequent instances back to the original statement instead of duplicating the requirement. A table of contents and an index will make the SRS easier to modify. Storing requirements in a database or a commercial requirements management solution makes them into reusable objects.

Traceable

A traceable requirement can be linked backwards to its origin and forward to the design elements and source code that implement it and to the test cases that verify the implementation as correct. Traceable requirements are uniquely labeled with persistent identifiers. They are written in a structured, fine-grained way as opposed to crafting long narrative paragraphs. Avoid lumping multiple requirements together into a single statement; the individual requirements might trace to different design and code elements.

How Do You Know If Your Requirements and SRS Exhibit These Attributes?

The best way to tell whether your requirements have these desired attributes is to have several project stakeholders carefully review the SRS. Different stakeholders will spot different kinds of problems. For example, analysts and developers can’t accurately judge completeness or correctness, whereas users can’t assess technical feasibility.

You’ll never create an SRS in which all requirements demonstrate all these ideal attributes. However, if you keep these characteristics in mind while you write and review the requirements, you will produce better requirements documents and you will build better products.

To learn more about how to write requirements in a way that all stakeholders have a clear understanding of development needs,
visit The Essential Guide to Requirements Management and Traceability

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles. Karl Wiegers is an independent consultant and not an employee of Jama Software. He can be reached at ProcessImpact.com. 


Jama Software’s onboarding process is thorough and comprehensive. You’ll get a great understanding of the platform’s full functionality and how you can leverage it to get the most from your investment. However, because Jama Connect is so customizable and can be used in so many ways, the onboarding process is just a starting point.

We’ve seen great success with organizations that hold monthly user groups. This creates a feedback loop and collects information to pass to Jama and executive sponsors. Relying on feedback from those who are working in the platform on a daily basis is imperative to adjusting and optimizing configuration and processes. Monthly user groups also give Jama Connect users a platform to share best practices, successes and challenges.

We also suggest that those who were assigned roles in the internal rollout plan play an active role in ongoing education and training for end-users. Holding weekly Jama office hours and monthly meetings allows you to continually optimize processes and answer questions and concerns from your team.

Below are a few things to consider and processes to set in place in order to find the most success with Jama Connect.

Joining the Jama Software Support Community

Organizations that set up continual, structured training related to Jama Connect are often the most successful. With that said, even if you decide not to leverage Jama Professional Services, we still have a plethora of resources to help you through implementation and beyond. Jama Support Community is a forum for Jama users to interact and collaborate with other users and with Jama support engineers. It’s full of resources for everyone from novices to masters, including tutorials and webinars, help guides and FAQs, feature requests and announcements and a robust knowledge base.

Creating an Implementation Plan

Having an implementation plan is the best way to keep your program on track. Your implementation plan should identify and document the key business outcomes you plan to achieve by using Jama. It should also outline your desired deployment approach, identify initial projects to start with and establish a high-level timeline.

We often recommend that organizations complete their Jama rollout in phases. If you start with a small group or department, you can spend time teaching them to be experts. That small group then becomes evangelists — a great asset as you complete your rollout to the rest of the organization.

Successful organizations often pair these early adopters with new users to help them get up to speed with the new process. Assigning roles and responsibilities related to the rollout and implementation of Jama reduces the risk of things falling through the cracks. Assigned roles also allow everyone within the organization to know where to direct questions or concerns, and who to reach out to for more training and additional resources.

Assigning Key Implementation Roles

In addition to the executive sponsor that we mentioned earlier, consider assigning the following roles during your implementation of Jama Connect:

Program Manager

The program manager is the primary point of contact for the Jama team and is responsible for the day-to-day management of the overall deployment of Jama Connect within the organization. Responsibilities include: coordinating resources; scheduling and presiding over meetings; communicating and facilitating decisions; and informing the Jama team of issues or concerns.

Core Implementation Team

In addition to the program manager, the core implementation team will work with the Jama team to define how Jama will be used in your organization. The core team should comprise employees who understand the overall processes and goals for implementation. They serve as empowered representatives of the different teams that will use the platform.

Change Manager

The change manager role may be performed either by the sponsor or the implementation lead and is vital to the success of Jama at your organization. This person works alongside the core implementation team to encourage their involvement in the Jama solution and to troubleshoot concerns. The change manager communicates regularly across the organization to build Jama knowledge and works to allay concerns and/or issues inherent in change. Prior to rolling out Jama Connect, the change manager is responsible for identifying and coaching team leaders and champions of Jama within your organization.

Jama Administrator

The Jama administrator is responsible for learning how to configure your instance of Jama using the administrative functions and also handles ongoing configuration and admin duties. This person will become a power user within the organization who will support other users, understand the impact of modifications to the system configuration, and implement configuration changes as appropriate. The Jama administrator will be heavily involved in the initial implementation and instrumental in governing configuration change management over time. (Note: This person may also be your program manager.)

IT/Systems Administrator

For organizations installing Jama on their internal networks (i.e., the tool is not hosted in Jama’s cloud), the IT/system administrator(s) are responsible for the initial installation and setup of Jama within your team’s production environment, including database, server and application configuration. Additionally, this person is responsible for ongoing system administration including XML back-ups, indexing, upgrading, permissions, etc. For Jama-hosted customers, this role may be limited to user management. When applicable, the IT/System Administrator(s) are responsible for provisioning and configuring the Integration Hub server.

Engaging Jama Software Professional Services

Jama is powerful and adaptable. The platform can be configured in countless different ways to fit your specific needs. To that end, Jama is not a “set it and forget it” kind of platform; it grows as you do. For Jama to be most successful, you must define exactly how you’ll use the platform and configure it to fit your specific processes.

That’s where Jama Professional Services comes in. They’ve helped thousands of customers figure out the optimal way for Jama Connect to be configured based on specific customer needs. Leveraging Professional Services speeds up the time to launch Jama and gives new customers confidence that their adoption will be successful. In fact, we’ve seen that time to value decreases significantly for customers who engage Professional Services.

The Jama Professional Services team partners with you to adapt Jama to fit your current product development processes and aids in the adoption of Jama within your organization. Professional Services helps you with the three stages that we outlined below – alignment, launch and adoption — each with best practices to align Jama with your business so you can quickly achieve sustainable results now and in the future.

Rollout Stages

Every organization is different, and your implementation plan should be tailored to the specific needs of your stakeholders. At Jama Software, we typically view the implementation in three key stages:

Alignment
  • Planning
  • Discovery
  • Design and Configuration
  • Validation
Launch
  • End-User Orientation
  • Initial Deployment Support
  • Post-Launch Refinement
Adoption
  • Optimization
  • Best Practice Guidance
  • Monthly Working Sessions

The implementation plan is your roadmap to success. This is the time to be thorough, thinking through the full impact of the rollout and considering each step you need to take to ensure success. This example rollout plan was created to give new Jama users an idea of what a successful rollout looks like.

Ongoing Internal Training

For many organizations, Jama is the lifeblood of their product development process. It’s incredibly important that you set up ongoing training and feedback loops within your organization to keep up with best practices, resolve challenges, and optimize your usage of Jama Connect.

This can take shape in many ways, but you can start by identifying how your organization works best:

  • Does your team thrive in a classroom setting?
  • Does your team prefer online tutorials or self-paced learning?
  • Should your training be formal or less formal?

These questions should help you formulate how you’ll conduct ongoing internal training.


Best Practices for Writing Requirements Better requirements lead to clearer, more effective communication between a product’s stakeholders — creating ripple effects across the entire organization including greater transparency; less rework; and, accelerated development without sacrificing product quality. While writing requirements is both an art and a science that will vary by context, there are a few best practices to consider.

In an ideal world, every individual user, business, and functional requirement would exhibit the following qualities: complete, correct, feasible, necessary, prioritized, unambiguous, verifiable, consistent, modifiable, and traceable.

We recently created an infographic of best practices to help keep teams aligned and reduce the chance of rework and product failure.

Download the full infographic to learn learn more about writing requirements, including:

  • Understand the problem
  • Define requirements hierarchy
  • Let the designers design
  • Be unambiguous
  • Use requirements templates and group discussions
Read the full infographic to see our tried and true best practices for writing requirements.

 

Ask Jama Release Management Webinar

Because we’re always looking for ways to support and enable our customers’ success, we’ve created this Ask Jama webinar series to keep you up to date on new product information, best practices, and tips and tricks on how to best use the platform. By popular request, the topic of this upcoming webinar will be Release Management options in Jama Connect. 

Ryan Moore, a Jama Connect expert and a consultant from our Professional Services team, will be discussing options for managing releases within Jama Connect. Concepts we’ll be covering include:

  • Leveraging Jama’s release field
  • Re-use and synchronization
  • Branching vs. mainline approaches

We’ve also made sure to include plenty of time to answer your questions around release management (or other relevant topics) during the event.

Date:        Wednesday, July 22nd, 2020
Time:        8:00 – 9:00am PST
Presented by:

 

Ryan Moore – Consultant, Jama Software
Ryan is a Business Consultant on the Professional Services team at Jama. He works directly with customers to implement Jama Connect, and help navigate requirements management, through best practice guidance.

Watch the recording now!

WATCH NOW

 

Cities may be opening up, but many engineering teams continue to work remotely on product development as companies slowly reopen.

Has your team found its rhythm? If your organization hadn’t planned for a distributed team, staying aligned without jeopardizing quality, efficiency, or timelines could still feel challenging. Jama Software helps the distributed engineering teams of global companies like Grifols, SITA, and Einride work seamlessly and successfully, and has for years.

Here’s what they say works best to keep the product development process on track.

1. Intuitive technology

Intuitive technology is user-friendly by design. It improves efficiency and momentum on a distributed team. Technology like this helps onboard team members, keep them aligned to projects, and connected to team members and their work.

Jama Software customer insight: Grifols

Healthcare leader Grifols adopted Jama Connect™ to help manage the product development process between teams in different countries. They cite the user-friendly, intuitive platform as a key reason they can bring everybody up the speed on changes so quickly. Right away, teams feel comfortable and encouraged to participate, comment, and engage in robust discussions.

“In the long distance between California and Spain, I feel like I’m connected to the team.”

– Carmen Pazos, Diagnostic Divisions R&D Instruments Senior Manager, Grifols
Read the whole story

2. Centralized change management

Scattered engineering teams still face evolving regulations and requirements for increasingly complex products. When teams can manage change like reviews and requirements from a single, central location the risk of rework or miscommunication goes down. Relevant stakeholders that collaborate, iterate, and issue approvals in a visible area never lack context.

Jama Software customer: SITA

Multinational company SITA wanted to align remote teams and facilitate effective collaboration around requirements. They chose Jama Connect to get an efficient, easy way for cross-functional teams to review requirements and a centralized, accessible repository for all the company’s requirements.

“Jama Connect has allowed us to get more people from our other offices involved in the collaboration process … People can come into the system at a time that suits them and review things. And we know their comments will be seen by everybody else.”

– Alistair McBain, Sr. Business Consultant, SITA
Read the whole story

3. Real-time data sharing

The product development process requires teams that work with structured, live data, even when remote. They need to be able to define, review, and validate it at any time. Critical functionality of the product they’re working on could depend on it. Communication among teams and stakeholders needs to go beyond the basics of collaboration. It’s about more than just a conversation or a simple text edit.

Jama Software customer: Einride

Einride’s feature-based development process uses the Jama Connect platform to identify which feature should receive the highest priority for development. The collaborative elements of the Comment Stream feature helps distributed engineering teams communicate critical changes to each other as part of their daily operations. For example: Einride develops features at a fast pace, often enhancing the functionalities of their electric freight vehicles after they’re deployed. Teams need to react fast and change tracks if necessary — and collaborate with each other early in the process.

“This is the biggest challenge —  to know what feature has the highest priority to be improved and/or developed…as we don’t have hundreds of developers, it’s crucial for us to know this as soon as possible.”

– Sabina Söderstjerna, Team Lead, Einride
Read the whole story

 

Learn more about how Jama Software can help you improve collaboration in your product development process.

 

Explore Resources

 

We’ve stayed in contact with our Jama Connect customers as they’ve transitioned to a remote work reality. Teams are working through a lot of changes as they manage new product timelines, supply chain disruption and new market demands. Through it all they continue to prioritize innovation and timelines.  

One common theme emerged among these teams: Productivity in remote work demands teams take time to evaluate how they can optimize the Jama Connect platform to work smarter. Areas of focus: Teams want to improve their process, help people become more efficient, and take advantage of all the platform’s capabilities. 

Here’s the breakdown.

 

1. Optimize the way you use Jama Connect to improve your process.

 

When you go remote, it’s easy to be tempted by the plethora of communication tools. They all have their time and place. But engineering teams require more focus and tighter alignment. Collaboration and communication tools built into the context of where the work is actually being done helps reduce confusion and minimize disruption. 

Jama Connect ensures decisions get made inside the process, not in silos. There’s not an email here, or a Slack communication there to explain what needs to happen next. Everyone stays on the same page—a crucial need when your teams are remote. You reduce the risk of building off the wrong information which can cause delays and rework. 

Learn more in Optimizing Your Product Development Process Through Team Collaboration: Strategies for Systems Engineers 


2. Check the way you use the technology in Jama Connect. 
 

When your teams work remotely, the ways you’re not using your technology to its fullest potential can become glaringly apparent. Every Jama Connect technology capability, even ones that aren’t about collaboration, take on greater importance.

Tightening product traceability is a best practice Jama Connect customers supporting remote teams recommend. The way companies do business is changing fast, and the ability to manage change is critical. When requirements traceability is carried out correctly, teams can accurately assess the impact of changes, track the full history of product development, keep everyone in sync, and consistently improve the quality of the products being built — in every project, and every release.

In Jama Connect you can extend traceability beyond the engineering processes to link development and test activities back to the business rationale. And, coverage analysis can help a team find gaps and understand positive and negative progress quickly. 

You can learn more in Five Tips for Requirements Traceability.  
 

 3. Educate your teams about the Jama Connect tools.

 

Now’s the time to take advantage of the full collaborative capabilities of the Jama Connect platform. Tools like Review Center make it easy for remote teams to work together.  

 In the Review Center, you can send items like systems specifications or test plans for an unlimited amount of reviews with as many contributors as you want, including engineers and testers. Everyone in that review receives an email notification and can approve, reject, and give feedback on every individual requirement or section of a document that needs review. You can keep track of who contributed, what their role is, how much time they’ve spent in the review, and their overall level of completion. 

Learn more about the Review Center in Best Practices for Jama Connect Review Center.

As countries begin to open up, we’ll be here to update you on ways to adjust your teams and workflows so you can maintain momentum. Check back often.

 

Get more help optimizing Jama Connect so you can improve efficiency and productivity for your remote teams. Learn about our Rapid Optimization Workshops, now available as a remote service.READ MORE

 

remote collaboration Einride webinar

A must-see webinar about remote collaboration is now available in our Resource Center. Matt Mickle of Jama Software and Sabina Söderstjerna from our autonomous transport customer Einride demonstrate how the Jama Connect platform helps remote teams communicate effectively and stay productive. 

Learn how Jama Connect supports a feature-based development process for Einride.

Sabina shares best practices Einride teams uses as they improve and develop different features through Jama Connect. During her session you’ll learn: 

  • How Jama Connect capabilities help identify which feature should receive the highest priority for development—an extremely helpful benefit if you don’t have a team of hundreds of developers to help you. 
  •  How the collaborative elements of Comment Stream and Review Center in Jama Connect impact Einride’s decision-making.  

The remote collaboration enabled by Jama Connect helps Einride’s Core Team fulfill its mission, despite physical distance. Together, they can ensure that the product built meets the specifications and requirements outlined.  

See the key functions that enable remote collaboration in Jama Connect.

In Matt’s session, he works directly in the platform. You’ll see how Jama Connect works as a modern replacement for legacy requirements management tools, and how collaboration features set it apart. 

The goal is for Jama to be a very easy-to-use tool, for it to be very user-friendly so that a lot of people can jump in and get started right away. – Matt Mickle, Senior Consultant, Jama Professional Services

Matt covers three methods of communication and collaboration: 

  • Collaboration Stream: How to create actionable communication streams to elicit feedback from stakeholders. 
  • Reviews for Feedback and/or Approval: How to bring selected people together to get targeted feedback on a small section or component, or to get sign off on a larger body of work. 
  • Single Source of Truth: How to keep the conversations in one place and connected to ensure nothing gets missed and you don’t have to chase down context. 

Learn remote collaboration best practices and see how Jama Connect helps remote teams work more efficiently.
 

Don’t miss it!

Watch the webinar

 

Remote collaboration is here to stay. Your remote engineering teams can adapt to the new reality without jeopardizing quality, efficiency, or product development timelines if they plan ahead. But first, they have to know what to look for.

Anticipate new challenges in remote collaboration.

Face-to-face, quickly assembled meetings and hallway chats aren’t options anymore. That matters when it’s time to make critical decisions. Suddenly, speed and consensus seem impossible, even though they’re crucial to your product development process.

Tools like Zoom, Slack, and shared docs can only help to a certain extent. They remain important communication tools for remote workers. But they can’t keep up with the communication demands for your virtual engineering teams building complex products.

Maintain alignment in team communication and collaboration.

Successful communication among remote engineering teams requires alignment.  Teams need to be able to define, review, and validate requirements in real-time to ensure the right team has the right information at the right time. Critical functionality of the product they’re working on could depend on it. 

Successful collaboration goes beyond a conversation or a simple text edit. It has to be structured, to:  

  • Focus on the product being built.
  • Include context to inform the conversations and decisions being made. 
  • Provide broad visibility into the development process to manage change. 

Four best practices to help engineering teams adapt to remote work.

All this is easier said than done, especially when remote collaboration wasn’t expected and hadn’t been part of a business’ regular product development process.  But Jama Connect customers who already support remote teams in their daily business shared their insights with us. We’ve collected them here to help you.

1. Establish a common definition of success.
Teams need alignment on what they’re building so they don’t waste time. Clarify expectations up front. What do the terms “define,” “build,” and “test” mean, for instance? What does success look like based on feedback loops such as customer interviews and design reviews?

2. Empower better decision making.
Ensure the whole team clearly understands the “why” at the beginning of a project. You’ll equip everyone with what they need to make better decisions. Good decisions require situational awareness, comprehension of impact, and a way to gather input from others – and these all start with the “why.” Clearly defined responsibilities empower those involved to initiate and resolve follow-up questions and issues.

3. Tighten up your traceability.
Certain industries need to demonstrate compliance with regulations. Traceability analysis proves your system holds up under regulatory demands and meets contractual terms. Coverage analysis tightens this process, and helps teams find gaps and understand positive and negative progress. Extend traceability beyond engineering processes to link development and test activities back to the business rationale. 

4. Collaborate with purpose.
Connect everyone on the team to relevant data that’s tied to the work. Don’t make decisions outside the process, such as in documents or emails. This can help speed the decision process, reduce costly rework, provide proof of critical decisions for compliance and ensure teams hit development timelines. 

Want more best practices and tips? Watch a recording of our webinar, “Ask Jama: Best Practices for Remote Collaboration with Jama Connect.”

 

Last month 1,150 professionals registered for our Best Practices for Writing Requirements webinar — our biggest webinar audience ever. Effective requirements writing continues to gain momentum as an urgent topic among product development teams across all industries. We get why.

The impact of clear and effective communication among stakeholders reverberates throughout organizations, and can:

  • Improve the quality of the requirements process.
  • Reduce rework.
  • Foster a culture of transparency.
  • Enable employees to work faster without sacrificing quality.

These benefits validate strong requirements writing as a crucial building block for an efficient workflow, and every business should want to perfect the skill.

Clarity, from market need to detailed requirement.

You can have the best builders and greatest minds on your side. But as our Manager of Business Consulting Preston Mitchell explains in the webinar, poor requirements writing compromises team collaboration and trust, kills innovation, and ultimately results in a product that doesn’t do what you want it to do.  It undermines your entire requirements management process.

There’s a lot of things around writing better requirements, it can be a great goal in and of itself. But it’s even better in that it leads to other efficiencies in your business. – Manager of Business Consulting Preston Mitchell

Preston breaks down the path from “need” to “requirement” into three parts: Understand the problem, define the requirement hierarchy, and improve requirement quality. Within each section, he identifies best practices that ensure you keep the market need — and user need — visible for your entire team and provides examples that show you how to do so. Watch the webinar now to see what you missed.

Top-of-mind questions answered — and new ones you never thought to ask.

  1. How can you detect a poorly worded requirement?
  2. What kinds of words add ambiguity to your requirements language?
  3. What’s the difference between requirements and design specification?
  4. What do you need to include when you write a strong, clearly defined problem statement?

In addition to best practices, Preston details how Jama Software can help improve your requirements authoring. There’s also a Q and A at the end, so you can hear specific, real-world examples from people want to apply great requirements writing to their business today.

Add these important writing practices to your skill set and refine your product development process.  You can watch a recording of the webinar in our resources center right now.

 

requirements management plan

Developers often want to freeze software requirements following some initial work and then proceed with development, unencumbered by those pesky changes. This is the classic waterfall paradigm. It doesn’t work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline.

What is a Requirements Baseline?

A requirements baseline is a snapshot in time that represents an agreed-upon, reviewed, and approved set of requirements that have been committed to a specific product release.

That “release” could be a complete delivered product or any interim development increment of the product. When stakeholders “sign off” on requirements, what they’re really doing is agreeing and committing to a specific requirements baseline (whether they think of it in those terms or not).

Once the project team establishes a requirements baseline, the team should follow a pragmatic change control process to make good business and technical decisions about adding newly-requested functionality and altering or deleting existing requirements.

A change control process is not about stifling change; it’s about providing decision-makers with the information that will let them make timely and appropriate decisions to modify the planned functionality. That planned functionality is the baseline.

Typically, a baseline is also given a unique name so that all the project participants can refer to it unambiguously. And good configuration management practices allow the team to reconstruct accurately any previous baseline and all its components.

Implementing a Requirements Baseline

Whereas the scope definition distinguishes what’s in from what’s out, the requirements baseline explicitly identifies only those requirement specifications that the project will implement. A baseline is not a tangible item but rather a defined list of items. One possible storage location is a software requirements specification (SRS) document.

If that SRS document contains only—and all—the requirements for a specific product release, the SRS constitutes the requirements baseline for the release. However, the SRS document might include additional, lower-priority requirements that are intended for a later release.

Conversely, a large project might need several software, hardware, and interface requirement specifications to fully define the baseline’s components. The goal is to provide the project stakeholders with a clear understanding of exactly what is intended to go into the upcoming release.

Perhaps you’re storing your requirements in a requirements management solution, rather than in documents. In that case, you can define a baseline as a specific subset of the requirements stored in the database that are planned for a given release.

RELATED: The Gap Between the Increasing Complexity of Products and Requirements Management

Storing requirements in a solution allows you to maintain an aggregated set of both currently committed requirements and planned future requirements. Some commercial requirements management tools include a baselining function to distinguish those requirements (perhaps even down to the specific version of each requirement) that belong to a certain baseline.

Alternatively, you could define a requirement attribute in the solution to hold the release number or another baseline identifier. Moving a requirement from one baseline to another is then a simple matter of changing the value for that requirement attribute.

The attribute approach will work when each requirement belongs to only a single baseline. However, you might well allocate the same requirement (or different versions of the same requirement) to several baselines if you’re concurrently developing multiple versions of your product, such as home and professional versions. Tool support is essential for such complex baseline management.

When following an incremental or iterative development life cycle, the baseline for each iteration will represent just a fraction of the overall system’s functionality.

A small project my team once worked on took this approach. This project worked in three-week release cycles. For each cycle, the BA specified the software requirements that were to be designed, coded, integrated, and verified during the next three weeks. Each requirements baseline was therefore quite small. In a classic agile approach, the product grew incrementally toward full functionality as the developer periodically released useful versions to the users.

RELATED: How to Perform Better Impact Analysis on Upstream and Downstream Relationships

When to Perform a Requirements Baseline

Business analysts sometimes struggle with exactly when to define a requirements baseline. It’s an important decision because establishing the baseline has the following implications:

Formal change control begins. Change requests are made against an established baseline. The baseline. therefore, provides the point of reference for each proposed change. Make sure your change control process and players are in place before you define any project baselines.

Project managers determine the staffing levels and budgets needed. There are five dimensions to a software project that must be managed: features, quality, schedule, staff, and budget. Once the features and quality goals are defined in the baseline, the project manager adjusts the other three dimensions to accomplish the project’s objectives. It can work the other way, too. If staff, budget, and/or schedule are pre-established by external forces, the baseline composition is necessarily constrained to fit inside the project box bounded by those limits.

RELATED: Getting the Most from a Requirements Management Tool

Project managers make schedule commitments. Prior to baselining, requirements are still volatile and uncertain, so estimates are similarly volatile and uncertain. Once a baseline is established, the contents of the release should be sufficiently well understood so that managers can make realistically achievable commitments. The managers still need to anticipate requirements’ growth (per their requirements management plan) by including sensible contingency buffers in their committed schedules.

Baselining requirements too early can push your change process into overdrive. In fact, receiving a storm of change requests after defining a baseline could be a clue that your requirements elicitation activities were incomplete and perhaps ineffective. On the other hand, waiting too long to establish a baseline could be a sign of analysis paralysis:  perhaps the BA is trying too hard to perfect the set of requirements before handing them to the development team.

Keep in mind that requirements elicitation attempts to define a set of requirements that is good enough to let the team proceed with construction at an acceptable level of risk. Use the checklist in Table 1 to judge when you’re ready to define a requirements baseline as a solid foundation for continuing the development effort.

Table 1. Factors to Consider Before Defining a Requirements Baseline

Business Rules Determine whether you’ve identified the business rules that affect the system and whether you’ve specified functionality to enforce or comply with those rules.
Change Control Make sure a practical change control process is in place for dealing with requirement changes and that the change control board is assembled and chartered. Ensure that the change control tool you plan to use is in place and configured and that the tool users have been trained.
Customer
Perspective		 Check back with your key customer representatives to see whether their needs have changed since you last spoke. Have new business rules come into play? Have existing rules been modified? Have priorities changed? Have new customers with different needs been identified?
Interfaces See if functionality has been defined to handle all identified external interfaces to users, other software systems, hardware components, and communications services.
Model Validation Examine any analysis models with the user representatives, perhaps by walking through test cases, to see if a system based on those models would let the users perform their necessary activities.
Prototypes If you created any prototypes, did appropriate customers evaluate them? Did the BA use the knowledge gained to revise the SRS?
Alignment Check to see if the defined set of requirements would likely achieve the project’s business objectives. Look for alignment between the business requirements, user requirements, and functional requirements.
Reviews Have several downstream consumers of the requirements review them. These consumers include designers, programmers, testers, documentation and help writers, human factors specialists, and anyone else who will base their own work on the requirements.
Scope Confirm that all requirements being considered for the baseline are within the project scope as it is currently defined. The scope might have changed since it was originally defined early in the project.
TBDs Scan the documents for TBDs (details yet to be determined). The TBDs represent requirements development work remaining to be done.
Templates Make sure that each section of the SRS document template has been populated. Alternatively, look for an indication that certain sections do not apply to this project. Common oversights are quality requirements, constraints, and assumptions.
User Classes See whether you’ve received input from appropriate representatives of all the user classes you’ve identified for the product.
Verifiability Determine how you would judge whether each requirement was properly implemented. User acceptance criteria are helpful for this.

 

RELATED POST: 8 Do’s and Don’ts for Writing Requirements

You’re never going to get perfect, complete requirements. The BA and project manager must judge whether the requirements are converging toward a product description that will satisfy some defined portion of customer needs and is achievable within the known project constraints.

Establishing a baseline at that point establishes a mutual agreement and expectation among the project stakeholders regarding the product they’re going to have when they’re done. Without such an agreed-upon baseline, there’s a good chance someone will be surprised by the outcome of the project.

And software surprises are rarely good news.

To learn more about how to write requirements in a way that all stakeholders have a clear understanding of development needs, download our eBook, Best Practices for Writing Requirements.

READ THE EBOOK

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at ProcessImpact.com.