by John Parker | Aug 2, 2012 | Business Analysis, Uncategorized |
Enfocus Solutions Inc. has teamed up with Karl Wiegers to bring you a requirements management education video series. The 35 videos comprising the series delineate all aspects of requirements management, from simple concepts (“What Is a Requirement?”) to detailed explanations of industry standards (“Version Control”). Karl Wiegers, autho of Software Requirements Second Edition, Creating a Software Engineering Culture, Peer Reviews in Software: A Practical Guide, among others, is a respected industry guru and advisor. With this training, CIOs, business analysts, and project managers can be sure they’re gathering the right information, listening to stakeholders, and writing traceable, comprehensive requirements. Video Synopsis According to IEEE, a requirement is a condition or capability that must be met or possessed by a system component to satisfy a contract, standard, specification, or other formally imposed documents, as well as a documented representation of such conditions or capability. Functional requirements are descriptions of how the system should behave (shall statements), while descriptions of how well the system should perform are non-functional requirements (quality expectations). Additionally, requirements may represent constraints on the development process of the system (the video provides a great example). Watch the Karl Wiegers video...
by Karl Wiegers | Jun 25, 2012 | Business Analysis, Uncategorized |
Use cases are recognized as a powerful technique for exploring user requirements. The great benefit they provide is to bring a user-centric and usage-centric perspective to requirements elicitation discussions. The business analyst employs use cases to understand what the user is trying to accomplish and how he envisions his interactions with the product leading to the intended user value. Putting the user at the center is much better than focusing on product features, menus, screens, and functions that characterize traditional requirements discussions. And the structure that use cases provide is far superior to the nearly worthless technique of asking users “What do you want?” or “What are your requirements?” As with most new software development techniques, use cases have acquired a bit of a mystique, some misconceptions, overblown hype, and polarized camps of enthusiasts who will all try to teach you the One True Use Case Way. In this series of three articles (adapted from my book More about Software Requirements), I share my perspectives on when use cases work well, when they don’t, and what to do when use cases aren’t a sufficient solution to the requirements problem. The Power of Use Cases I’m a strong believer in the use case approach. Users can relate to and review use cases because the BA writes them from the user’s point of view, describing aspects of the user’s business. In my experience, once they get past the discomfort of trying a new technique, users readily accept the use case method as a way to explore requirements. I’m often asked how to write requirements specifications so that users can read and...
by Karl Wiegers | Jun 14, 2012 | Business Analysis, Uncategorized |
The CEO of a major corporation who was present when I described requirements traceability at a seminar asked, “Why wouldn’t you create a requirements traceability matrix for your strategic business systems?” That’s an excellent question. He clearly saw the value of having that kind of data available to the organization for each of its applications. If you agree with this executive’s viewpoint, you might be wondering how to incorporate requirements traceability into your systems development activities in an effective and efficient way. Tracing requirements is a manually intensive task that requires organizational commitment and an effective process. Defining traceability links is not much work if you collect the information as development proceeds, but it’s tedious and expensive to do on a completed system. Keeping the link information current as the system undergoes development and maintenance takes discipline. If the traceability information becomes obsolete, you’ll probably never reconstruct it. Outdated traceability data wastes time by sending developers and maintainers down the wrong path, so it’s actually worse than having no data at all. Requirements Traceability Procedure If you’re serious about this effort, you need to explicitly make gathering and managing requirements traceability data the responsibility of certain individuals. Otherwise, it just won’t happen. Typically, a business analyst or a quality assurance engineer collects, stores, and reports on the traceability information. Consider following this sequence of steps when you begin to implement requirements traceability on a specific project: Select the link relationships you want to define from the possibilities shown in Figure 2 from the first article in this series on requirements traceability. Take another look at the second article in...
by John Parker | May 31, 2012 | Business Analysis, Uncategorized |
Requirements management tools can be generally categorized into three categories based on their intended purpose: – Product Requirements – Software Requirements – Enterprise Project Requirements At first glance, these may appear similar, but in actuality they differ significantly. Product requirements must be carefully defined and then handed off to engineering and design. Once manufacturing and distribution begins and products have been shipped, changes in requirements are a moot point. For software, new requirements and changes to existing requirements are included in software updates. Software can be upgraded frequently overtime, while products often cannot. This fundamental difference often makes requirement elicitation, development, and management techniques very different depending if software or a product is being developed. Enterprise projects are a totally different thing. For example, for many enterprise projects we don’t build software, we buy it. Let’s examine what is different about requirements for enterprise projects. Intricately Tied to Underlying Business Processes Enterprise projects usually involve and require fundamental changes to a business process, which the new or changed system must support. Extreme care must be exercised to ensure that the requirements are defined for the optimized “To Be” process, not the problematic “As Is” process. Since changes to business processes can be a moving target, this can wreak havoc on the requirements definition process. It is important to keep in mind that defining system requirements for a poorly designed or flawed business process is a waste of time and money. Software Development May Not be Required The solution for many enterprise projects is to use commercial off the shelf software (COTS), such as an ERP or CRM system. Requirements...
by Karl Wiegers | May 16, 2012 | Business Analysis, Uncategorized |
Great business analysts are grown, not simply trained. The job includes many soft skills that are more people-oriented than technical. An organization’s BAs likely will come from diverse backgrounds, which could include the business side, the IT side, and subject matter experts. Whatever their backgrounds, new BAs will have gaps in their experience, knowledge, and skill sets because of the unique bridging and communication-centric nature of this vital project role. This article looks at some of the skills and knowledge issues associated with business analysts who come to the job from various previous positions. Anyone pursuing a career as a BA should study an inventory of relevant knowledge, such as the Business Analysis Body of Knowledge developed by the International Institute of Business Analysis (www.theiiba.org). I’ve developed a suggested business analyst job description (available from www.processimpact.com/goodies.shtml). All BAs should determine the job knowledge and skills that pertain to their situation, identify their own knowledge gaps, and actively seek the information that will let them do a first-rate job. Classroom training, eLearning courses, self-training, coaching, and practice will all be useful methods for bridging the gaps. New BAs also can benefit from mentoring from those who have more experience, perhaps in the form of an apprenticeship. The Former User Many corporate IT departments employ business analysts who migrated into that role following a career as an end user of business applications. These individuals have a solid understanding of the business and the work environment, and they easily can gain the trust of their former colleagues. They speak the user’s language. They know the existing systems and business processes. On the...
