Requirements gathering

Software simulation tool integrated with IBM’s requirements product

iRise Connect for IBM Rational Requirements Composer will soon be available. This integration, built on IBM’s open Jazz technology platform will make high-fidelity iRise visualizations instantly accessible from within IBM Rational Requirements Composer.

This integration is designed to eliminate wasteful cost overruns and delays by ensuring IT organizations are documenting and tracking the right business needs the first time.

The iRise solution gives business analysts and project managers the ability to build working simulations of software before development begins. (Read “Simulation software a cure for hospital’s requirements validation ills” to learn how one customer uses the product.)

IBM Rational Requirements Composer is a collaborative toolset that provides the ability to visually capture requirements information as process sketches, storyboards, user-interface sketches, and rich text to better articulate and communicate the context of requirements.

The combination of the two products gives requirements professionals the ability to embed live, high-fidelity software visualizations directly into the Requirements Composer product by leveraging iRise SmartView. Business analysts, business stakeholders, developers, projects managers, and other IBM users can interact with “live” visualizations and fully experience simulated pages, scenarios, and masters directly within the Requirements Composer environment.

The visualization assets are then published in real time from iRise to the Requirements Composer repository and can be linked into the web of requirements artifacts.

For more information, visit iRise’s website.

What are the top software tools of 2008?

As the year starts to wind down, we at SearchSoftwareQuality.com are looking back at what took place during 2008. One thing that we’re focusing on is the tools and solutions that were released. In an effort to help our readers understand what tools are available to help them, we are creating a guide to tools released in 2008 to be published in January.

In order for us to do that, we need your help identifying tools that were released. The tool categories we’re focusing on:

• Software testing
• Test management
• Code quality
• Application security
• Software requirements
• Agile development
• Project management
• Application lifecycle management
• Application performance monitoring & management

Please send us information about tools released between Jan. 1, 2008, and Oct. 31, 2008, that you’d like us to consider for the guide. The tools must be new products or significant upgrades. And you must include the following information:

• Product name and version/model number
• Company name
• URL for the product
• Product or company logo
• Date product was released
• Tool category (see above)
• Product description
• If it’s an upgrade, features that were added
• What makes it innovative?
• Details about how it performs
• Details about its ease of use and manageability
• Pricing

Send your product submissions to Editor@SearchSoftwareQuality.com by Friday, Dec. 12.

What are your software requirements headaches?

Understanding what your stakeholders want in an application can be challenging, to say the least. You need to know what questions to ask and get your stakeholders to explain their needs and wants. It requires not just eliciting requirements but also validating that what you’re ready to send to the developers is in fact what your stakeholders want. Communication with the stakeholders and with the developers is essential.

That’s just one headache business analysts often have. Others that I’ve heard people talk about:

• Transitioning from legacy requirements or documents (Word, Excel files) to use cases
• Transitioning from per-project requirements to per-system requirements
• Being asked to specify many of the user interface details as requirements (Too much UI detail in the requirements constrains the designers and takes away from the functional requirements)
• Managing requirements across the enterprise
• Managing requirements for reusable components (How to achieve effective reuse across the enterprise)

Additionally, more people are asking about how to manage and define software requirements in agile environments. How do you handle changing software requirements?

Do any of those issues cause headaches for you? Are there other things related to software requirements that create problems for you or you need more information about? Tell me about your pains — be as specific as you want.

Think of me as your doctor: Tell me where it hurts, and I’ll try to help you get rid of the pain. Only I won’t charge you for an office visit.

One solution to software requirements challenges

If you’re responsible for making sure stakeholders get the software that they want, then you’re probably all-too familiar with the four aspects of software requirements — elicitation, elaboration, validation, and acceptance.

Increasingly I hear how an iterative approach is best and how tools can help. One tool that sounds like it could help is Blueprint’s Requirements Center. It provides a single environment for everything — there’s no need to leave the environment.

The elicitation tool provides “rapid requirements capture.” You can use it to identify and capture the relationships between the different requirements, you can capture images to include, you can capture data definitions, and you can import requirements from Excel spreadsheets.

The elaboration tool helps you start to make sense of everything. You use it to start to model the business process and the applications. It provides a GUI center to show interfaces of the software. And because it records the traceability of requirements, you can see what is impacted if a requirement is changed.

When it comes to validating what you have with stakeholders, you can create an end-to-end workflow diagram. You create a simulation to review with the stakeholders, and then gather their feedback. That feedback is entered directly into the center. You also have the option of passing the simulation around, and stakeholders can enter their own comments.

When the stakeholders give their OK, signaling that you’ve got it right, you can then generate the standard documents required for signoff. And those signoffs can be recorded on the server. When all is said and done, you’re giving the designers “a very comprehensive and complete diagram of what stakeholders want,” said Tony Higgins, vice president of products at Blueprint.

Additionally, the requirements center can generate all of the functional tests that correspond to the requirements. These are “ready-to-run” tests, Higgins said.

Last week Blueprint released new features for the requirements center. Blueprint Requirements Center 2009 Feature Pack Two introduces the Blueprint Resource Center. It provides analysts with instructional materials such as videos, samples, and best practices; company-specific templates and guides; advice from Blueprint experts; and syndicated articles and tips from Web communities and blogs.

Feature Pack Two also enhances integration with HP Quality Center. Now, requirements definition meta data (including visual requirements, GUI prototypes, security requirements, and data elements) are seamlessly integrated with HP Quality Center’s Requirements Management and Test Management modules. In addition, HP Quality Center users also have the ability to import and leverage assets within Blueprint’s elicitation module to provide early visibility and to speed IT development and quality assurance teams.

Want to see how the various modules work? Blueprint provides online demonstrations of its Blueprint’s Requirements Center.

Agile tool tracks app changes

Even when you think you’ve elicited and validated all of your stakeholders’ requirements, you’re still bound to have users who are unhappy with an application or a feature within an application.

Determining what the problem is and what users would prefer, however, can be challenging. But a feature in OutSystems’ All-In-One Agile Suite can help.

In its recently announced suite, OutSystems includes Embedded Change Technology (ECT), an automated mechanism for collecting business users’ feedback directly from a running Web application. Users point and click on the area in the applications where they want a change to be made and write their comments in the ECT pop-up window. The feedback is then made available to project managers and developers for review from the Agile Network’s Projects component.

More than that, members on the development team can use ECT. Business analysts can use it to validate requirements, QA engineers and testers can use it to flag problems and post comments, and programmers can use it to communicate with testers.

OutSystems is targeting Web 2.0 development teams who follow agile methodologies. The suite, which will be available in early November, includes the following:

• ECT

• New Agile Network — a portal for accessing OutSystems’ purpose-built Agile project management tools, online training, and knowledgebase of expertise

• Agile Platform 4.2 — an enhanced version that simplifies the creation of Web 2.0 applications leveraging Ajax

Visit OutSystems site to see demonstrations of its All-In-One Agile Suite.

If you’re struggling to give your stakeholders what they want in an application or if communication on your team is lacking, it’s worth checking this tool suite out.

Software security is everyone’s problem

Good news about Web security is much rarer than it should be. There was some encouraging news recently, however. A report from WhiteHat Security found that over the course of a year, 66% of known vulnerabilities were corrected. When one considers how terrifying security reports usually are, happy surprises such as these are to be celebrated.

But before you break out the champagne, it might be prudent to read about the report’s other, terrifying findings. Spoiler alert: CSRF attacks are primed and ready for massive destruction. As you can see, application security is a moving target. Once you’ve protected against one threat, attackers come at you using a different weapon.

Sadly, a small percentage of software professionals realize how important requirements gathering is for security. Business analysts can educate themselves with Kevin Beaver’s tip on writing software requirements that address security issues and Rob Apmann’s Q&A on how to address security during requirements gathering. And project managers should check out a free chapter from Software Security Engineering: A Guide for Project Managers. Requirements Engineering for Secure Software offers a gentle introduction to the subject.

We receive many questions from readers about requirements gathering for applications that need protection built into them. A site that processes credit cards or any other kind of sensitive information must be created with security as a major priority. Rob Apmann recently advised how to gather requirements for a payroll application. The first thing to do, he said, is to gather non-functional requirements such as the scale of the system and whether it is Web-based “so that you start with an architecture that will be secure and meet your deployment needs.”

Like industry experts have been saying for years, security needs to be addressed at every part of the development life cycle — requirements, design and architecture, programming, testing, and QA.