Tag: Elicitation

The Importance of Requirements Traceability

Written by Cynthia Low on January 20, 2009. Posted in Articles. 1 Comment on The Importance of Requirements Traceability

Discovering a list of requirements and then not linking them to design, construction and testing often results in the delivery of a system that may not fully support the business process which it was intended to automate. Only through traceability can the project team ensure that all requirements are implemented. Traceability assures the business stakeholders that the developed system supports their original requirements.

Client Story: A Large Financial Institution

A large financial institution recognized that their IT projects were consistently not meeting the expectations of the project stakeholders. Delivery of systems with missing or incorrect business requirements resulted in modification of business process or expensive workarounds so that the system could be used. Consequently, many costly change requests were generated, often to implement requirements which were identified during the requirements phase of the project lifecycle.

Lessons Learned

Each element of the design must come from the business requirements.
In order for the system to deliver value it must support the process. The system is based on the design. Therefore, the design must be based on the process the system is to support.
To ensure expectations are met, test cases should be based on business requirements, not technical design.

The client did an analysis of several projects which delivered systems that did not fully meet requirements and determined that the root of the problem was an inconsistent methodology to elicit and document business requirements. After a search process, IAG was selected to assess the organizational maturity in the area of requirements. IAG was also tasked with developing a customized optimal requirements process based on industry and organizational best practices as well as IAG practical experience gained on hundreds of requirements projects.

Recipe for Success

In order to determine the root cause of the requirements deficiencies, IAG conducted a Requirements Management Maturity Assessment (RMMATM). The RMMA is used for the identification and improvement of an organization’s business analysis, requirements definition and requirements management capabilities. The assessment evaluates not only organizational capabilities with respect to process, but also staff competency, practices and techniques, tools employed, organizational infrastructure and support, deliverables, and results which are currently being achieved.

IAG conducted a series of structured interviews with stakeholder groups including Business Analysts, Project Managers and key members from Lines of Business and IT. Additionally, IAG administered an assessment survey and a Business Analyst competency test to measure perceived and actual skill levels of the staff responsible for requirements management. Several common themes arose while conducting interviews with stakeholder groups, one of which was the lack of traceability after the requirements had been discovered. A number of key stakeholders went so far as to voice their skepticism about the success of any new requirements methodology since past projects had been implemented without incorporating all requirements discovered under previously-used practices. It was determined that the root cause of these past failures was that once business requirements were documented and handed over to the design and construction teams, they were not referenced going forward. In fact, test cases usually tested the design rather than the business requirements; if requirements did not make it into the design, testing would not catch the problem.

“For the first time, this approach provides us with a flexible and adaptable approach that takes us from our clients’ true business requirements seamlessly through software design. We also generate our test cases right at the start and ensure traceability through our SDLC.”

J.S., AVP Individual Systems

Upon completion of the RMMA, IAG produced a Requirements Practices Guide which included both an elicitation framework androbust tracking of requirements from discovery through testing and implementation. IAG then demonstrated the value of traceability through the success of several projects, in which the Financial Institution engaged IAG as a partner during the Requirements Phase. The Financial Institution now writes functional requirements which are derived directly from the business requirements discovered when describing the business process. These requirements are managed using a Requirements Traceability Matrix connecting them to design and testing elements and even linking change requests created during the course of the project. This has resulted in a dramatic decrease in missed requirements as demonstrated by a 75%reduction in change requests on similarly-sized projects.

Advice for Project Managers

When managing your project’s requirements consider what was needed in this client’s case: a better process to create functional requirements for each business component to be automated, as well as, the ability to trace those requirements through design, construction and testing to ensure each business requirement is satisfied as intended.

The client’s expectations are that the system performs functions to support their business process, as documented in their business requirements. Therefore, you have to reflect your client’s business process in the functional requirements. Ultimately, you must deliver a system which allows the business to function in its desired state. You can achieve this by creating a functional requirement for each business component to be automated – but – don’t forget to trace each requirement through the development lifecycle. Both are needed to ensure the system meets stakeholder expectations.

Duncan McDonald is a Senior Consultant at IAG Consulting (http://www.iag.biz/) with over 20 years of experience in bringing practical advice to clients across many industries. Duncan has completed dozens of large-scale requirements projects with IAG’s clients as a lead requirements facilitator and requirements architect. As a requirements trainer and best practices advisor, Duncan has also supported a variety of large clients in becoming more efficient in requirements discovery and management practices. Duncan is a sought-after consultant, who brings pragmatic solutions to clients that want dramatic performance gains.

Can I have My Requirements and Test Them Too?

Written by Cynthia Low on December 15, 2008. Posted in Articles.

A study by James Martin, An Information Systems Manifesto (ISBN 0134647696) has concluded that 56% of all errors are introduced in the requirements phase and are attributed primarily to poorly written, ambiguous, unclear or missed requirements Requirements-Based Testing (RBT) addresses this issue by validating requirements to clear any ambiguity or identifying gaps. Essentially, under this methodology you initiate test case development before any design or implementation begins.

Requirements-based testing is not a new concept in software engineering – in fact you may know it as requirements driven testing or some other term entirely – and has been indoctrinated in several software engineering methodologies and quality management frameworks. In its basic form, it means to start testing activities early in the life cycle beginning with the requirements and design phase and then integrating them all the way through implementation. The process to combine business users, domain experts, requirements authors and testers; and obtain commitments on validated requirements forms the baseline for all development activities.

The reviewing of test cases by requirements authors and, in some cases, by end users, ensures that you are not only building the right systems (validation) but also building the systems right (verification). As the development process moves along the software development life cycle, the testing activities are then integrated in the design phase. Since the test case restates the requirements in terms of cause and effect, it can be used to validate the design and its capability to meet the requirements. This means any change in requirements, design or test cases must be carefully integrated in the software life cycle.

So what does this mean in terms of your own software development lifecycle or the overarching methodology? Does it mean that you have to throw out your Software Development Life Cycle (SDLC) process and adopt RBT? The answer is no!. RBT is not an SDLC methodology but simply a best practice that can be embedded in any methodology. Whether the requirements are captured as use cases, as in Unified Process, or scenarios/user stories, as in Agile development models, the practice of integrating requirements with testing early on helps in creating requirement artifacts that are clear, unambiguous and testable. This not only benefits the testing organization but the entire project team. However, the implementation of RBT is much cleaner in formal waterfall-based or waterfall derived approaches and can be more challenging in less formal ones such as Agile or Iterative-based models. Even in the most extreme of the Agile approaches, such as XP, constant validation of requirements is mandated in the form of ‘customer’ or ‘voice of the customer’ sitting side-by-side with the developers.

To illustrate this, let us take the case of an iterative development approach where the requirements are sliced and prioritized for implementation in multiple iterations. The high-risk requirements, such as non-functional or architectural requirements, are typically slated in initial iterations. Iterations are like sub-projects within the context of a complete software development project. In order to obtain validated test cases, the team consisting of requirements authors, domain experts and testers cycle through the following three sets of activities.

Validate business objectives, perform ambiguity analysis. Requirement-test case mapping.
Define and formalize requirements and test cases.
Review of test cases by requirements authors and domain experts.

Any feedback or changes are quickly incorporated and requirements are corrected. This process is followed until all requirements and test cases are fully validated.

Simply incorporating core RBT principles into your methodology does not imply that fewer errors will be introduced in the requirements phase. What it will do is catch more errors early on in the development process. You have to supplement any RBT exercise by ensuring you have the means to build integrated and version-controlled requirements and test management repositories. You must also have capabilities to detect, automate and report changes to highly interdependent engineering artifacts. This means proper configuration and change management practices to facilitate timely sharing of this information across teams. For example, if the design changes, the impact of this change must be notified to both the requirements authors and the test teams so that appropriate artifacts are changed and re-validated.

Automating key aspects of RBT also provides the foundation for mining metrics around code and requirements coverage, and can be a leading indicator of the quality of your requirements and test cases. True benefit from the RBT requires a certain level of organizational maturity and automation. The business benefits from having increased software quality and predictable project delivery timelines. Thus, by integrating testing with your requirements and design activities, you can reduce your overall development time and greatly reduce project risk.

Sammy Wahab is an ALM and Process consultant at MKS Inc. helping clients evaluate, automate and optimize application delivery using MKS Integrity. Mr. Wahab has helped organizations with SDLC and ITSM processes and methodologies supporting quality frameworks such as CMMI and ITIL. He has presented Software Process Automation at several industry events including Microsoft Tech-Ed, Java One, PMI, CA-World, SPIN, CIPS, SSTC (DoD). Mr. Wahab has spent over 20 years in technical, consulting and management roles from software developer to Chief Technology Officer with companies including Tenrox, Osellus, American Express, Parsons, Isopia Compro and Iciniti. Mr. Wahab holds a Masters in Business Administration from the University of Western Ontario.

Defining Requirements within a Short Time Frame

Written by Cynthia Low on October 15, 2008. Posted in Articles. 3 Comments on Defining Requirements within a Short Time Frame

Recent industry studies show that modern software projects on average spend 40 percent of their effort on rework. As a result, over 60 percent of software projects overrun budgets, miss schedules and substantially reduce delivered functionality. Without a clear idea of how to set requirements, most software development projects will face either significant rework or fail altogether. Over the past few years, Agile methodologies appear to be helping reduce this problem. This whitepaper will explore techniques of capturing requirements within Agile teams.

Wikipedia says that, “The term Agile Software Development refers to a group of software development methodologies that promotes development iterations, open collaboration, and process adaptability throughout the life-cycle of the project.”

So, if we apply a sports analogy, using Agile methods to develop software is like a series of sprint races. Developers are focused solely on successfully completing the next iteration, which is often due within a matter of weeks, and they zero in on defining their requirements to achieve that short-term goal.

In other words, Agile teams don’t produce any requirements specifications that are not absolutely critical to making it clear to the team what is expected of them in the short term. So, the question becomes: How do you decide what requirements are “just enough” to complete the next iteration?

There are a number of factors that need to be considered, when deciding what techniques and how much level of detail to provide when defining requirements for an Agile team. These considerations should include:

Team size and the proximity of team members
Skill and experience of the team
Has the team worked together before?
Complexity of the requirements
Complexity of the software.

Keeping the above considerations in mind, you will need to decide which techniques you will want to use and how much detail you will want to provide while using these techniques.

Common techniques include:

Verbal Communications. Verbal communications, perhaps using a whiteboard to capture key thoughts, is typically the fastest way to define a requirement. However, what this approach makes up for in initial speed, it doesn’t ensure that all stakeholders are in the loop. Plus, participants may not all remember exactly what was decided after the meeting breaks up. It is all too easy to have a different recollection of details that were discussed two weeks ago. This can lead to misunderstanding of requirements during development and testing, and will be reflected in inaccurate product user guides and training material. So you may have saved time initially, but wasted more time in the long run.

So when is verbal better than written communication? Agile methods promote face-to-face interactions, but that can be impractical in cases where teams are scattered across the globe or even across a city. Relying only on verbal communications is a last resort, to be used only when short-term time gains are worth more than the longer term problems this approach can create.

Story Cards. A popular and valuable technique within Agile development teams is to create a story card. These story cards tend to provide a text-based description of who wants to do what and why, along with perhaps a picture of the screen and some test scenarios. This technique works well for very small features but may not scale well for larger or more complex features that integrate and depend on other features.

Requirements Lists. Often a common place to start from a product scoping point of view is to create a hierarchical “Requirements List” which captures in text form an organized and grouped list of functional requirements, technical requirements, business drivers etc. Often these text descriptions can be enough to clearly articulate what the requirement is For example a technical requirement such as, “The application must support IE 6 and IE 7,” does not really need any additional explanation. However a requirement such as “The application must be able to define which users can have access to specific functionality and data” will need much more detail. The point is to only expand on requirements that truly need more details.

Use-Case Flows. Sometimes to truly understand the overall flow of a more complex requirement use-case flows or simulations are required to capture “just enough” requirements. However from my point of view it typically is not a good idea to use “use cases” to document complex logic or business rules such as authorization logic. These types of requirements are often better documented in text or tabular formats. For example, a simple 2×2 table showing the roles on one axis and what they can do on the other axis is a much more efficient way to convey authorization business rules than embedding alternate flows into use cases.

Simulations. Simulations can add great value to really bring a concept to life, but adding every single detail into the simulation can take too much time. And, frankly, it is sometimes difficult for developers to reverse-engineer a simulation and extract a discrete set of requirements. It is much easier for an Agile team member to read a simple table showing who can do what, than to run through a simulation and reverse-engineer the same information. Also, it is possible to spend too much time doing elaborate simulations that don’t add enough value for the time and effort they can take to develop.

Everyone will have their personal preference as to when to use what technique for communicating requirements, but the key is for the team to work together and agree upon when it makes sense to use different techniques and not “force” a technique when it clearly can be done more easily another way.

General Repository. No matter what techniques you decide to use to document requirements, keeping these requirements details/artifacts in a central repository and linking them to each other in an organized manner is critical to the collective success of your Agile team. Relying on people to keep track of endless email trails and simple document repositories with manually maintained links is not the answer. People are too busy to do it, and, most likely, the data repositories will not be kept up-to-date. Because of that, any repository needs to do whenever possible to automatically create and maintain these links based on how the artifacts are organized. For example, if a use case refers to a screen on a given step, then that screen should be automatically linked to that step in the repository.

So how do you know what is enough detail? Your team will let you know when things require more details. Part of working within an Agile team is to expect the need for requirements clarification throughout the project. In traditional waterfall, this was almost discouraged and under the good intentions of change management. However, within Agile, it is expected and embraced, which takes some getting used to for Agile newbies.

Recap

This topic is much deeper than can be covered with this small article, but the key points are

Make a conscious decision on the level of detail you want but expect to tweak that during development.
Choose the right technique for the requirement you are trying to describe.
Make sure you keep an integrated central repository that links together the multiple requirements artifacts.

Martin Crisp is CTO of Blueprint Systems. He can be reached at [email protected]

I Don’t Have Time to Manage Requirements; My Project is Late Already! Part IV

Written by Cynthia Low on October 1, 2008. Posted in Articles.

Requirements Summary

In this series we have provided an overview of requirements management, a description of the requirements management plan and its components, and some tips on how to negotiate for realistic time frames that include just enough time for the appropriate amount of requirements management.

Before we conclude, we need to make some important distinctions among terms that are sometimes used interchangeably. These distinctions are important, since they are not only invaluable for requirements planning, but also help clarify roles and responsibilities.

A Few Key Terms

The following are some terms which, when clarified, will aid in requirements management:

Project Management and Requirements Management.

Project management focuses on delivering the end product within constraints, such as time and cost. Project management includes the entire effort to produce the end result, of which requirements management is a part.

Requirements management focuses on defining the features, functions, capabilities, and characteristics of the end product, ensuring that they are defined completely and correctly.

Business Analysis and Requirements

Business analysis is the work of producing requirements. Business analysis can be performed in one project phase or many.

Requirements are the end result of completed business analysis work. Again, they describe the features, functions, characteristics, and capabilities of the end result of the project.

Projects, Products and Solutions.

Project. Endeavor or undertaking that produces a unique end product, service or result.

Product. We are using the term as it is defined in the PMBOK® to mean the end result of the project.

Solution. There can be both business and technical solutions. The business solution is defined by the sponsor and business subject matter experts. The technical solution, if there is a technical component to the project, is defined by the technical subject matter experts. After requirements have been defined, they are turned into a solution to the business problem that needs solving.

Life Cycles, Methodologies, Approaches

Life cycles describe the phases that take the project from its inception to its end. While it can be used to describe products (for example, the life cycle of a new pharmaceutical drug), concepts (life cycles of safety), or of living things (fleas and flowers), we are going to think of a life cycle of the project. Project life cycles are important, because they need to be managed.

Methodologies define how to get from the beginning to the end, usually through prescribed processes and templates. Frequently, phases and phase names are provided, as well as tasks to be completed within each project phase. The methodology may or may not prescribe multiple phases for completing business analysis.

Approaches are like “hybrids,” not quite life cycles and not quite methodologies. Examples are agile and Waterfall. Proponents of certain approaches often refer to “methods,” such as agile methods or SCRUM.

Summary of Requirements Management

Below are activities that need to be performed, either formally or informally, with a great amount of rigor or with practically none. They are closely aligned with the BABOK, version 2.0 but, since that document has not been published, we have avoided specific references to the Knowledge Areas. These are processes that need to be performed, regardless of the methodology or approach used.

Planning Business Analysis

These are the set of activities included as part of planning the business analysis phase, or phases, of a project. Whether planning for a new process, new or enhanced software, a new bridge or a feasibility study, deliverables and tasks must be identified, planning processes must be identified or created, roles and responsibilities must be agreed on, metrics established, and a plan for communications, formal or informal, must be created. Although not all project life cycles include a formal phase(s) for business analysis, the activities that comprise business analysis need to be taken into account.

As described in the series Overview, one of the key deliverables is the Requirements Management Plan, which is a set of documents that can be expected to change over time. The subsidiary plans that comprise the Requirements Management Plan are executed and updated at different points during business analysis.

Elicitation

This set of activities includes gathering stakeholder requirements and ensuring that their needs have been understood. Effective elicitation requires the ability to ask the right questions, listen to and synthesize responses, and record customer requirements. These skills are required for effective project management as well. Finally, elicitation tasks include determining elicitation techniques that are appropriate for the project.

Enterprise Analysis

In a nutshell, this process includes tasks to recommend, which projects to undertake by completing feasibility studies and cost benefit analyses. Once projects are undertaken, recommend the product scope.

Analysis

This set of activities includes the progressive elaboration of requirements from highest level to subsequently lower levels of detail, as more becomes known. Its purpose is to ensure that the business needs are truly understood and that requirements are defined completely and correctly. The requirements need to be elaborated in enough detail so that business clients are satisfied that their needs will be met, and the development team can create the end product or service.

Solution Assessment and Validation

This knowledge area describes how well the solution, or end product, solves the stated business problem and meets the approved requirements. This knowledge area includes activities related to making sure the end product matches the stated requirements, and is closely related to Quality Management.

Requirements Management and Communication

This set of activities involves the packaging of requirements to provide the level of documentation agreed upon in the Requirements Communication Plan (Business Analysis Planning and monitoring), taking into account the various audience preferences for format, level of detail, and frequency of communication. It also covers the handling of conflicts and issues. Finally, this knowledge area describes managing changes to the product and version. Because changes have to be managed across business analysis, it relates not only to Communications Management, but also to Integration Management.

Below is a matrix summarizing the interrelationship between the knowledge areas for Requirements Management, as shown in the BABOK, and project management, as framed in the PMBOK.

Integrating Requirements Management and Project Management

Final Words

In summation, requirements management, whether done formally or informally is a vital aspect of project management. Without the requirements management plan, the overall project management plan is incomplete. Taking the time to plan and manage requirements will lead to a better end product and increases the chances of having satisfied stakeholders.

In addition, if we revert to when requirements were not managed, we can expect to see the cost of projects and defect repair, as well as scope creep continue to increase. However, if we spend too much time on requirements management, we are at risk of creating a burdensome process that will delay the project. It is important, then, to apply an appropriate amount of requirements management rigor to our projects to ensure that we have:

Thought about the approach we will take
Identified the business analysis deliverables
Developed a requirements schedule
Planned for requirements communications
Clarified important roles and responsibilities
Communicated our plan to our sponsor, ensuring an understanding of the requirements management plan and its importance

This care will help all stakeholders in planning their time and encourages their active participation on the project.

References
Ambler, S. (last updated March 3, 2007), Agile Modeling, retrieved on January 7, 2008, from http://www.agilemodeling.com/essays/changeManagement.htm and http://www.agilemodeling.com/essays/examiningBRUF.htm

Davis, A. Just enough Requirements Management Part 1, retrieved on January 7, 2008, from http://conferences.codegear.com/article/32301.

IEEE Standard 610,

1990,International Institute of Business Analysis (2006). A Guide to the Business Analysis Body of Knowledge, version 1.6.

Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK®) (2000 ed.). Newtown Square, PA: Project Management Institute.

Software Engineering Institute (SEI’s) Square Project updated 5/12/05.

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP

are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com/.

In this Edition: Managing Requirements, Getting Motivated, IIBA News and New Blogs

Written by Richard Lannon on September 15, 2008. Posted in Articles.

Once again we have a mix of the latest part of a continuing series requirements management plus plenty of other new and interesting contributions about the business analysis world – what’s going on now and what to look for in the future – that are sure to give you something to thinks about. Plus we have an update about what’s new at the IIBA. And, of course, our bloggers are back, including one new one.

I Don’t Have Time to Manage Requirements: My Project is Late Already! Part III. In this, the third in their series, Elizabeth and Richard Larson discuss the appropriate requirements management process for different projects; too much can be as bad as too little.
Creating Motivation through Discovery. Richard Lannon talks about the importance of motivating people. He says it’s all about asking the right questions, listening and understanding – and then taking the appropriate steps.
Will the First CBAPs Be a Credit to the Profession? Well Will You? Marcos Ferrer bills his blog as one of the world’s shortest blog. But he puts a very important question to all CBAPs. We hope you’ll answer him!
The Cost of Validation. New blogger, Jonathan Malkin takes a look at how much is invested in developing systems but often nothing to ensure the system works, yet, as he points out, Solution Assessment and Validation is an important area in BABOK.
IIBA Launches Computer Based Testing of the CBAP Exam and a Letter from the President September 2008 are two important information pieces from The IIBA section of this site.
Defining Roles in the BA Life Cycle. Terry Longo asks if a single BA can be skilled in all aspects of the solution life cycle. He thinks single BA ownership makes sense but finding the right individual can be tricky – but not impossible.

Also don’t forget to check out our webinars and the Business Analyst Times book shop. And let us know what you think about this edition of BA Times.

Many thanks.

Adam R. Kahn
Publisher, Business Analyst Times
[email protected]