Articles for 'Karl Wiegers'

Business analysts must identify external interfaces and the constraints they impose on architecture and detailed designs. Conscientious designers will ensure that all the pieces of a complex system fit together correctly across their mutual interfaces. New components that developers integrate into an existing system must also conform to established interface conventions.

Many books provide guidance on how to create effective user interface displays, a vital aspect of the user’s experience with a software application. But a user often must navigate through a series of screens to perform a task. Making that flow sequence logical and efficient is also an important part of the user experience.

I’m a big fan of analysis modeling, drawing diagrams that visually represent various aspects of a software system and its requirements. One of my favorite models is the dialog map, which provides a convenient way to represent, validate, and improve how a user navigates through a user interface.

A reader wrote to me with questions regarding a development project that he thought involved too many requirements and too little flexibility around requirement priorities. (You’ve never heard of such a thing before, right?) 

Software consultant Tim Lister defined project success as “meeting the set of all requirements and constraints held as expectations by key stakeholders.” There’s a vast body of literature on software requirements. In contrast, little is written about the various kinds of constraints that stakeholders might impose on a software initiative. Identifying, communicating, and working within constraints are essential aspects of successful software development. Let’s begin with a definition:

“A constraint is a restriction that limits the choices available for a product’s specification, design, construction, configuration, or project management.”

A software initiative is subject to three major classes of constraints: product, project, and process.

Tools can amplify a software developer’s capability, but ineffective or inappropriate tool usage amplifies their shortcomings as well. Properly applied tools and practices can add great value to a project team by increasing quality and productivity, improving planning and collaboration, and bringing order out of chaos. But even the best tools won’t overcome weak processes, untrained team members, challenging change initiatives, or cultural issues in the organization. 

I like use cases. There, I said it, and I’m not sorry. Use cases have fallen out of fashion in recent years, being largely replaced by user stories on agile projects. The two techniques can coexist and complement each other, however.  Use cases offer several advantages that user stories lack. This article describes some of the many benefits that use cases can provide and why every business analyst (BA), product owner (PO), and software development team should include them in their tool kit.

Every decision-making group should first decide how they will arrive at their conclusions by selecting appropriate decision rules.  Too often, when people begin to collaborate on some initiative, they don’t discuss how they’re going to work together. An important—and sometimes adversarial—aspect of collaboration is making high-impact decisions that influence the project’s direction. 

Although use cases are valuable for many projects, sometimes event analysis is a more effective requirements elicitation technique. Valuable as they are, use cases aren’t the ideal tool for every type of product. A complementary requirements elicitation strategy is to explore the various events that a system or product could experience and how it should respond to each of them. The response depends on what state the system is in when it detects the event. Event analysis is particularly well-suited for middleware products and real-time systems that include both software and hardware components.

Many organizations acquire and adapt purchased packaged solutions (also called commercial off-the-shelf, or COTS, products) to meet their software needs, instead of building new systems from scratch. Software as a service (SaaS), or cloud, solutions are becoming increasingly available to meet software needs as well. Whether you’re using a package as part or all of the solution for a new project or implementing a solution in the cloud, you still need requirements. Requirements let you evaluate solution candidates so that you can select the most appropriate package, and then they let you adapt the package to meet your needs. This article describes several ways to approach requirements definition when you plan to acquire a commercial package to meet your needs.

 Here are six more practices that, again, virtually every project will find valuable. These are adapted from our book, Software Requirements Essentials: Core Practices for Successful Business Analysis.

Do you have to do them? Of course not—that’s your choice. The requirements police won’t hunt you down if you don’t. But if you know of any projects that won’t find at least five of them valuable, please let us know. We’ll notify the Guinness World Records people.

People sometimes ask me, “What’s the most important lesson you’ve learned about software development in all that time?” Here it is, lesson #4 of the 60 lessons in my book Software Development Pearls: A usage-centric approach to requirements and design will meet customer needs better than a feature-centric approach.  Let me describe why I believe this is such an important principle.

Rather than building systems in house, many organizations outsource development to contract development companies. They might outsource the work to take advantage of skills they do not have available in-house, to augment their internal staff, or in an attempt to save money or time. The outsourced development supplier could be located physically nearby, on the other side of the world, or anywhere in between.  The role of a business analyst is even more important on these projects than on a co-located project. If the team members are all in one location, developers can walk down the hall to ask the BA a question or to demonstrate newly developed functionality. This close collaboration can’t happen in the same way with outsourced development. Compared to in-house development, outsourced—and particularly offshore—projects face requirements-related challenges...

Whether you’re purchasing a package (also called commercial off-the-shelf, or COTS, products) as part or all of the solution for a new project or implementing a solution in the cloud, you still need requirements. Requirements let you evaluate solution candidates so that you can select the most appropriate package, and then they let you adapt the package to meet your needs.

There are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn’t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.