Tag Archive for: requirements engineering and management

Requirements Engineering

Requirements management (RM) is a challenge for many companies, partly due to the ambiguity involved in software development. First, you must understand the client’s requirements. Second, you must match those requirements to critical processes.

RM is a component of requirements engineering (RE), which bridges the divide between a client’s needs and what developers create. When done well, RE has the ability to create a solid framework for software development, which is critical since poor software engineering requirements management is a root of many project failures.

A CIO magazine study found that “Analysts report that as many as 71% of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure.”

In 1999, NASA built the $125 million Mars Climate Orbiter probe. The probe failed because it entered orbit 100 kilometers too close to Mars. The source of the error was incompatible specifications; an important component of RE.

Understanding the details involved in requirements engineering and best practices can set you on the path to successfully meeting client expectations.

What is requirements engineering?

Clients have a long list of goals when creating new software, and RE provides a framework for meeting those goals. Important needs are inventoried and transformed into a detailed set of requirements. Requirements development dictates future development activities and creates a blueprint for success.

The terms requirements management and requirements engineering are often used interchangeably, but they are different. RM is one piece of requirements engineering, and getting it right makes all the difference.

RE ensures that the problem a client wants solved is clearly defined and the solution is both accurate and effective. Essentially, RE transforms a real-world problem into a highly functional software solution.

RELATED POST: Requirements Management Tools and Software

The 4 steps of the requirements engineering process

The requirements engineering process has many potential pitfalls. Strengthening your RE process enables you to avoid many common challenges. The process serves as a compass, guiding you in determining the exact deliverables and doing so with greater accuracy. All important parties are on the same page about what steps need to be taken to achieve the desired outcome. Strengthen your RE process by considering the following:

Elicit requirements. Elicitation is about becoming familiar with all the important details involved with the project. The customer will provide details about their needs and furnish critical background information. You will study those details and also become familiar with similar types of software solutions. This step provides important context for development.

Requirements specification. During the specification phase, you gather functional and nonfunctional project requirements. A variety of tools are used during this stage, including data flow diagrams, to add more clarity to the project goals.

Requirements verification and validation. Verification ensures the software is implementing the right functions. In contrast, validation ensures the software is built to the customer’s requirements. If the requirements don’t go through the validation stage, there is the potential for time-consuming and expensive reworks.

Requirements management. During RM, you’re matching all the relevant processes to their requirements. You will analyze, document and prioritize the requirements – and communicate with relevant stakeholders. Any requirements that need modification are handled in an efficient and systematic manner.

As you implement the different components of RE, it also helps you get a sense of what should be excluded from requirements. Understanding this will help you focus more accurately on developing requirements and better meeting client expectations.

What information should be excluded from the requirements?

Requirements should be viewed as addressing a problem, but not necessarily as providing a solution. A requirement should clearly state what you want to solve, not how you want to solve it. Let’s take a look at guidelines for good requirements:

  • The requirement accurately defines the need of the stakeholder.
  • The requirement is testable.

A requirement needs to be clear and understandable, without the risk of ambiguity. An important step in developing good requirements is the review process. Does the requirement accurately express the needs of the stakeholders? Make sure to build in enough client reviews so that you can get early feedback and adjust as needed.

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

Common mistakes to avoid

There are many challenges that may occur as you develop your RE framework. Understanding potential issues can help you avoid them. Consider the following as you develop your processes:

  • Avoid scope creep. There is a temptation to add “just one tiny new requirement” to make the client happy. But these little changes add up and may have an impact on future activities, such as testing, documentation and more.
  • Resist the urge to “over-engineer.” Over-engineering can be tempting, especially when you want to make sure everything is just right for the client. But this overzealousness can backfire. Adding a little extra code because “I’m doing this, I may as well do that” might seem logical, these changes can create a ripple effect, putting requirements at risk in the future.
  • Build in enough feedback and reviews. Early feedback is essential to a project’s success. Build in frequent reviews and solid traceability to get feedback often and early.
  • Search for all the important stakeholders. You might think you’ve included all the important stakeholders, only to learn you missed one later on. Invest time early in the process to find any and all important stakeholders in order to avoid expensive reworks later in the process.
  • Identify potential resistance early in the process. Resistance can be an invisible but serious project problem. Learn to identify resistance early in the process so that you can work through it efficiently and early, getting everyone on the same page.

Awareness about these potential pitfalls can save you time, money and resources during the RE process. Also, look at your existing processes and whether they include enough traceability. Ensuring that deliverables meet requirements, for example, is much easier if every requirement is linked to at least one test. And traceability is an essential part of this process.

Engineers can then invest their energy into requirements that are failing the test and get the project back on track quickly.

Leveraging the right tools for success

Requirements engineering is critical to the success of a project because it tells everyone involved with the project what needs to be done. A project manager, who schedules tasks, can do so based on more accurate requirements. A requirements management software tool can greatly support successful RE, as it enables more efficient and optimized product and system development.

This type of tool can provide:

  • Clarity and visibility. Get broader visibility into what you’re building and why.
  • Live traceability. Ensure product quality and improve change management with complete traceability.
  • Decision tracking and fast reviews. Conduct virtual reviews of requirements, test cases, user needs and more.
  • Real-time collaboration. Immediately note and prioritize important decisions, pull in the required stakeholders and reference historical context to eliminate communication errors.

The right tool can help you transform RM as you easily track, review, sign off on and truly understand how and why you did certain things. As a result, you can streamline your product development process and increase efficiency, understand and respond to change, and establish a higher level of clarity and visibility.

See how Jama Connect can help with requirements engineering by downloading our solution overview.


Product development and delivery is more complex today than ever before. Modern products are multifaceted and multidisciplinary, with hardware, software, and various engineering approaches coming together in the name of superior customer experience. Many industries — medical device, automotive, and aerospace and defense, for instance — also require that complex product developers adhere to rigorous safety standards and regulations. Companies have to work effectively and efficiently if they’re going to keep their competitive advantage.

Despite this, many teams are still using Word and Excel to manage requirements for these very complex products. This means they’re missing real-time collaboration and insights, end-to-end traceability, and integration with product testing, to say the least.

Learn why designing a reliable test strategy requires broad, strategic thinking by downloading our paper, “Verify, Validate, Trace & Test”

A recent report from Engineering.com found that while 90% of design and engineering teams agreed that products had become more complex in the last five years, a mere 15% relied on a dedicated requirements management solution. The rest still rely on a purely documents-based approach, even though using these tools to exclusively design, manage, and execute requirements presents an array of problems, including version-control issues, poor communication, inefficient collaboration, and lack of coordination.

The study found that the implications of poor requirements management were not to be taken lightly. Without a dedicated solution, teams were stuck with ineffective requirements management and were more likely to face product outcome failures (83% of respondents) and reprimands by regulatory agencies (62% of respondents).

On the other hand, the report found that not only did organizations using a dedicated requirements management platform in regulated industries receive fewer warnings, recalls, fines, or reprimands than those that didn’t, nearly half reported experiencing none of these issues at all.

Download our whitepaper to learn about the five biggest challenges of requirements management and how to conquer them.

Word documents that are hundreds of pages long, Excel spreadsheets packed with thousands of lines — sharing these ever-evolving files among multiple stakeholders and disparate teams throughout the development and testing process is cumbersome, frustrating, and time-consuming — not to mention risky. And with the market demanding flawless products delivered at record speeds, innovators can no longer afford that kind of inefficiency.

Using a dedicated requirements management solution, however, allows teams to stop wasting time and start innovating. For example, our customer, MediSync, reports that investing in Jama Connect has saved 80% of the time that would have otherwise been spent on meetings, sorting through versioned Word documents and emails, and consolidating feedback in review cycles.

To learn more about the growing number of organizations adopting product development solutions to manage the complexity of connect systems, download our eBook, Your Guide to Selecting the Right Product Development Platform.

Word and Excel undoubtedly serve a purpose. For early-phase documentation and for coordinating small, simple projects, they remain effective tools. But as product development grows more complex, teams need solutions that provide purposeful collaboration; connect globally-distributed team members; and accurately capture and facilitate feedback, decision making, and context for requirements under review.

To learn more about the limitations of a document-based approach and how to get the most out of your requirements management tool, download our eBook.

To learn more about requirements management, we’ve compiled a handy list of additional resources for you!

 

On a chance bus ride down MLK to our Jama office a few months ago I happened to share a seat with a colleague in our Engineering Department, Bryant Syme. He had only been working for Jama for a few months and to be perfectly honest I hadn’t spoken to him much yet. We talked a lot about recent events in the office, but also talked about some of his previous work experiences. This is the first time I had ever heard about Mob Programming and the many potential benefits it can bring to a team of engineers. It planted the seed for me to introduce it to my own team and eventually start evangelizing it to the rest of our department.

VC1A8278_male

What is it?

Mob Programming is a style of paired programming, but with the entire team involved instead of two developers. Every person involved in the story should be in the Mob Programming session and actively contributing, including Product Managers, DevOps and QA Engineers.

Think of Mob Programming as a tool for getting through larger, more obtuse stories and epics. The team will crowd around a single screen with one person driving and will talk through everything from acceptance criteria and design decisions, to implementation of the code and even test cases.

Mob Programming has many benefits:

  • Shared ownership over decisions.
  • Better quality code.
  • Ability to break through large tasks easily.
  • Team bonding through working together.
  • A great way to teach other team members various skills.

This style of work doesn’t need to be limited to programming. It could also be great to work on any project, from writing a document to planning for future work, to doing performance testing.

The tenets of Mob Programming

The main tenets of mob programming that everyone should follow are:

  • Use one keyboard and screen
  • Use a private room
  • Select a time keeper to rotate who is on the keyboard every 15 or 30 minutes.
  • Everyone gets time at the keyboard, even non-programmers.
  • Take a story from start to finish, or in other words: from planning to coding, to testing, to done.
  • Take breaks when you want.
  • A session should span an entire workday.

Each of these tenets are flexible and should be discussed with the group before starting. One thing I’ve had a lot of luck with so far is pausing the timer to do whiteboard planning, for instance. We also usually take however much time we need at the beginning of the session to sketch a rough plan of what we are going to do, in order to stay on task as people switch around.

One keyboard and screen

This allows the team to concentrate without the distraction of e-mail, chat applications or other work. Team members may come convinced that they will need to work on other activities since there won’t be enough to help with when they aren’t at the keyboard. I had such an encounter with one of my teammates who was certain that there would not be enough for him to do. You will need to remind them that this is not a normal meeting and that you need their full attention. In the case of my teammate, I conceded that he could bring his PC as long as he kept his attention on the task at hand. He agreed and ended up being so engaged that he rarely, if ever, looked at his own screen.

One rule you can bend here is that research on one screen can be boring for the team to watch and help with. This is an appropriate time for other team members to use their own PCs to help do research (as long as everyone is staying on task).

iStock_000055460038_male

Use a private room

This moves the team to another space both physically and mentally, and also prevents outside distractions. Other teams should respect that you have shut the doors and should not interrupt you. But if you are interrupted, team members should volunteer to chat with that person outside of the room to allow others to keep working.

Rotate who is on the keyboard every 15 or 30 minutes

Decide on a good time interval at the beginning of the meeting. I recommend 15 or 30 minutes depending on how many people are in the group, but other time increments are also fine. I’ve found that a group of 4 or less people works best with 30 minute intervals, wheras 5 or more works best with 15 minute intervals. Its just enough time to get some work done, but also enough for everyone to rotate through in the large group.

Bring a timer with a loud alarm. I usually use the Clock App on my iPhone and turn the sound way up. When the alarm goes off, whoever is at the keyboard should immediately take their hands off and let the next person rotate in, even if they were in the middle of typing. The thing to remember here is that it’s not about one person working while the others watch, as it is about everyone working on the same thing. Whoever else rotates in should easily be able to pick up where the last one left off.

A clock that resets itself is also ideal, since you don’t want to forget to start the timer.

VC1A1815_male

Everyone gets time at the keyboard, even non-programmers

Whoever is helping should have a chance at the keyboard, even if they are in a QA, PM or DevOps role. Remember that everyone is working on the same task and watching and directing what the driver is doing, and it should not matter much who is on the wheel. It’s ok to be a backseat driver in this situation.

Participation also keeps everyone at full attention! Keeping the same person or only developers will become boring for others in the room if they never get a chance to participate.

Take a story from start to finish

Even when coded, the story isn’t finished, it still needs to be tested! Work on your test cases as a team. Personally, I am a QA engineer and getting other team members to help work on making quality test cases is very validating and helps us be less black box.

Whatever is required to get that story into the “Done” column should be done during this session. In addition to getting higher quality code, test cases and automation, this also tears a lot of walls down between roles. A lot of our developers often don’t have much of an idea for what DevOps or QA engineers “do”. This is a perfect chance to get cross-team collaboration and boost how your team works together!

People are allowed to take breaks when they want

Bathroom breaks, coffee breaks, lunch breaks should not be discouraged, but be warned: people will want to keep working, so mandatory breaks may be needed!

Mob programming can also be exhausting, if someone needs a few minutes to take a breather, they should be allowed to simply leave and come back when needed.

A session should span an entire workday

This one has been difficult to schedule a lot of times. So far we have managed to schedule one full day and several half days of mob programming. Most literature I’ve seen on the topic so far recommends the full day, if possible, though. If individuals need to leave for meetings or other commitments, there should still be enough people left to absorb their absence.

Conclusion

Mob Programming is a great tool that can be used to effectively chop down and complete large stories and epics. Remember if you are trying this, review the tenets with your group, such as sticking to one screen and one keyboard, as much as possible.

This is also great for bringing other team members up-to-speed with certain design patterns or tools. Someone who never uses the command-line or has never dealt with a certain language before will likely get a chance to learn a lot.

Everyone in the room should be involved, don’t limit it to just programmers, or others will get bored and not be as engaged. Remember to invite everyone in your team to the session, including the Product Managers, QA and DevOps Engineers.

And of course remember to have fun! Odds are your team will have a blast and work just a little better together than before the experience.

Stop chasing down documents in DOORS and focus on the items within them that matter.

For many years, IBM’s Rational DOORS (v.9) has been a widely adopted Requirements Management (RM) tool for teams working with high-compliance systems engineering programs. Because it’s often sold into the enterprise as part of a larger IBM suite, its widespread use is sometimes a matter of default rather than choice.

If you’re like most of today’s systems-driven engineering organizations, you’re primarily in the business of producing complex, finished products and components, often involving a mix of hardware, software and firmware. You’re probably also in a hybrid-Agile development environment and figuring out how to scale that effectively.

In business, times change because needs change. Changes driven by the rise in software-driven products, the imperatives of on-time delivery, and extended supply-chain systems threaten to disrupt traditional, legacy manufacturing and engineering processes. Your teams are pressured to accelerate product delivery and manage growing complexity in distributed organization and supply chains, within products, and across a network of interrelated and interdependent products.

Jama is built to serve and evolve with the ways systems engineering teams build products. How is it different? Jama deconstructs documents into actionable items. You can easily see, grab and reuse items, and be confident that they’re current and include all related comments and status. Forget about wordy “reading assignments.” You can share specific work components with your team for review and approval, without the risk of compromising security or access permissions that document shuffling causes. And when it’s time to pull it all together again to submit or archive a controlled document version, Jama can do that, too.

Skeptical? Make us prove it to you. Sign up for a free 30-day trial and give us a shot. No installation required.

 

 

And one proven way to handle them with speed and finesse.

For product managers and their counterparts, the road to launch is a fight to keep every task, every detail and every change grounded in business goals. It’s not enough to be fast. Or to deliver the right product. You need to do both. Yet, the tools product managers depend on are often the weakest link, and not up to the tasks of fast-paced iterative development. But whatever product management tools and methodologies you’re using, you’ll still need to tackle these 10 challenges:

  • Engaging all the right stakeholders in the most effective, efficient manner (knowing who to involve, when and how)
  • Tracking product, program and project details while responding to a constant stream of new information
  • Finding critical information you need at the moment you need it instead of searching through emails, spreadsheets, SharePoint, tribal knowledge in team members’ heads, etc.
  • Keeping teams in-sync and updated on what they are planning, building, testing and releasing
  • Prioritizing and re-prioritizing what goes into each release, based on new information, insights and pressures from multiple voices—everyone from front-end users to engineers to sales to support
  • Revisiting decisions and changes because you haven’t been able to capture context, discussions or approvals in an accessible manner
  • Identifying opportunities to reuse and synchronize projects, items and components to reduce risk and save time
  • Navigating and mastering the complexity of products, projects, processes, teams and communication
  • Struggling to delight business customers while juggling overtaxed resources and tight deadlines
  • Ensuring on-time, within-budget delivery of the right product

 Check out The Product Delivery Problem (It’s Not You) to uncover the one surefire way to establish and maintain a strong connection between intended outcomes, development methodologies and customer value.

jama-the-product-delivery-problem-landing-page

Do you have any particularly problematic product challenges not listed here? Share what’s on your mind in the comments or send us a tweet and read our next practical product management and development post here.