Articles for 'Karl Wiegers'

Business analysts turn ambiguity into shared understanding—clarifying real needs, shaping solution direction, and aligning stakeholders and delivery teams. This article explores why top BAs consistently improve outcomes and how to strengthen the capabilities that make them indispensable.

Thinking outside the box. Making a paradigm shift. Looking at the problem in a brand-new way. Taking a fresh approach. These expressions all refer to changing how we look at a difficult problem to solve it in a more effective manner.

People naturally get stuck in their established ways of thinking. It’s all we know at any given time. But sometimes that's not sufficient. Instead of continuing to pursue the current strategy that doesn’t work, we must shake up our thinking, sometimes radically.

You have to determine which quality requirements are most important to your project’s success, and then state specific objectives for them so designers can make appropriate choices. This article describes an approach for identifying and specifying the most important quality attributes for your project, adapted from consultant Jim Brosseau’s method.

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.