Skip to main content

The Importance of Requirements Traceability

Written by Cynthia Low on . 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

  1. Each element of the design must come from the business requirements.
  2. 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.
  3. 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. 

The BAs are Coming! The BAs are Coming!

Written by Marcos Ferrer on . Posted in Articles.

BA Fire Alert!  How will the new Administration impact Business Analysis?  Please go to http://citizensbriefingbook.change.gov/ideas/viewIdea.apexp?id=087800000004t42&srPos=2&srKp=087 ASAP and vote!  There is a nationwide “brainstorming elicitation” being performed by the Obama transition team, and the idea in the link above is a BA clarion call!  This is your chance to be heard in an important new way, using a state of the art elicitation technique.

If you don’t like the idea you see, add your own, but PLEASE get involved – this is important.  It is a unique chance to lobby on a level playing field.  Tell your friends, your bosses, your professional colleagues, your government employee friends, spread the link by email, use your Linked In contacts, Facebook, the works!

The inspiration for the above initiative is that a different kind of Story from the Front has come to my attention. We are so consumed with our experience of BA (or its lack of practice in our immediate environment) that we don’t think about what this means for people’s lives.  Thinking about this is important; it keeps us in other people’s shoes, and is good practice in learning how to “say” things to be heard, supported, and gain consensus.

Check these samples out, and send me an email ([email protected]) letting me know which one(s) you relate to the most, and sharing YOUR story.

Story 1

“I certainly agree that business analysis has real value in the government sector. It may be interesting to note that I am currently engaged as a consultant in a Feasibility Study and Cost/Benefit Analysis for a state government project. I am proud of the techniques and skills that I, as a BA, can bring to the team performing the Feasibility Study and to the client who is fully committed to supporting the effort.  

“The business problem goes well beyond abstract notions of IT and process. It impacts thousands of children who are subject to abuse and neglect, foster and adoptive parents who take them under their care, case workers who become their advocates, and community organizations and private providers who deliver vital services.”

Story 2

“I recently was asked to join a government project for a federal government web service that was struggling with requirements.  With the support of another CBAP, we were able to help improve the requirements somewhat, but only with incredible resistance from the project management itself.  This resistance came in spite of the fact that CBAPs were hired specifically to satisfy the government that the requirements were being handled well.

“While the project will go on to “succeed”, there were cheap, powerful opportunities missed, all because project management had better ideas than stakeholders. I saw this as a direct “violation” of BA values, and did what I could to encourage stakeholder ideas. 

 “When you realize that the project would be a great benefit to this agency’s “clients”, it is a shame that these opportunities were missed. But I am confident that they will be  implemented in time – requirements get “paid now or paid later”, as always.

“As BA is increasingly better understood, I am guessing that this resistance will diminish.  The government clients were pleased enough with the CBAPs’ work, and felt they had been heard well when we were done.  The project management contract was not renewed, and one of the CBAPs was brought back to follow up with requirements on the development side.

“Like life, this was imperfect and messy, yet there is a positive trend in the outcome.  Clients ultimately love the integrity of the BA values and approach, and I love being a CBAP, and I love that the government “clients” in this case will get a better service from my contribution.”

Keep sending me your stories, and remember the people that we ultimately serve!

Thanks to my gentle readers for their frankness and willingness to share.

More shall be revealed.

Have fun!

Ten Bad-Ass BA Techniques

Written by Cecilie Hoffman on . Posted in Articles. 1 Comment on Ten Bad-Ass BA Techniques

Plus Four Fundamental Principles

Principle #1. Leave your ego at the door

  • You are a business analyst – you have a license to ask dumb questions; it is your responsibility and your job! So ask the dumb questions, admit you don’t know, ask for input, show work at early stages, don’t let your own ego-fears-pride get in the way of problem solving.
  • Put your team in the spot light, put yourself behind the curtain.

Principle #2. Authority is 20% given & 80% taken – take it!

  • Don’t wait for permission, ask for forgiveness.
  • Manage those meetings!

Principle #3. Acknowledge people

Sometimes you have to push people or ask them to do more than is normal to expect. You can thank them for their help but over time, your thanks may develop a hollow tone. Take the time to recognize people’s efforts in a way that means something to the individual; creative ways of saying “thank you” are remembered for a long time and create a positive impression and a good relationship.

  • Nominate them for an award
  • Send a message to their boss – what you needed, why the person’s professional conduct and timely response saved your butt
  • Send a message to the person
    • A “thank you” card – there are many cyberspace sites that offer electronic cards
    • A simple email message acknowledging the person’s effort
      Include a .jpg of a plate of tasty goodies like cookies, chocolates, or samosas

Principle #4. If you don’t fail on occasion, you aren’t trying hard enough

Progress and innovation come from holding on to the idea despite the inevitable series of failures. If the consequences of your taking initiative results in a backfire

  • Acknowledge verbally that you may have gone too far in your attempt to actively engage in moving the project along the path to success
  • Ask the person if there is a better way for you to accomplish your goal. Smile; deflect any barbs that might come your way.
  • Learn from the failure. Don’t get defensive – nothing ventured, nothing gained!

The Ten Techniques

Remember, these are the “bad-ass” techniques. Use them with care, especially if you are risk-adverse.

Managing meetings

1. Use “roll call” to obtain explicit decisions. In meetings (telephone or in person), do not accept silence as a response! Instead of asking, “do we all agree?” instruct people to express their concerns with this prompt, “If you disagree, speak up now.”

2. Provide a suggested agenda to focus activities at a standing meeting.

3. Use Actions-Decisions-Issues to record meetings.

Facilitating communication and understanding

4. Share bad news early

  • The sooner “management” or “leadership” knows there’s a problem, the sooner they can start working on it. 
  • If you use the red-yellow-green flag paradigm: extend the paradigm, “Pale Yellow” means “warning, this could get worse”; “Orange” means “one step away from Red”.

5. Did they read the document?
For documents that are in a draft form, include an unexpected phrase in a strategic location in the document, e.g., “300 Pink Elephants” – people will comment on it if they see it. Take care to remove the phrase before the document becomes a deliverable!

6. Treat requirements templates as guidelines

  • Provide all the information that is asked for, or explain why you can’t.
  • Don’t ignore the gaps, missing or unknowns, identify them!
  • Add the sections or references you think are missing

Conducting interviews

7. Send the list of topics you plan to cover in advance – no more than five general topics. If you have specific questions that will require research, provide those questions in advance.

8. Paraphrase as a way to keep a person talking without agreeing with what they are saying.

Establishing trust-based relationships

9.  Make a personal connection

  • Extend yourself beyond normal bounds to make a personal connection with the individual regardless of social group, ethnic background, and gender.
  • Ignore what you may have heard about an individual; do not allow another person’s negative assessment of that individual to prejudice you – make your own assessment, based on how that individual conducts him/herself with you.

Managing requirements

10. Get the Success Criteria and Success Metrics

  • Offer outrageously low or high metrics for targets to elicit a more realistic expectation for “success”
  • Accept the “solution” with grace; but continue to ask questions. Play the fool until the requirement (need) has success criteria and a way to measure it.

Cecilie Hoffman is a Senior Principal IT Business Analyst with the Business Analysis Center of Excellence, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. Her personal passion is cross-country motorcycle riding. She can be reached at [email protected]

Tackling Updates to Legacy Applications

Written by Cynthia Low on . Posted in Articles.

After 40 years of serious business software development, the issues involved in dealing with legacy systems are almost commonplace. Legacy applications present an awkward problem that most companies approach with care, both because the systems themselves can be something of a black box, and because any updates can have unintended consequences. Often laced with obsolete code that can be decades old, legacy applications nonetheless form the backbone of many newer applications that are critical to a business’s success. As a result, many companies opt to continue with incremental updates to legacy applications, rather than discarding the application and starting anew.

And yet, for businesses to remain efficient and responsive to customers and developing markets, updates to these systems must be timely, predictable, reliable, low-risk and done at a reasonable cost.

Recent studies on the topic show that the most common initiatives when dealing with legacy systems today are to add new functionality, redesign the user interface, or replace the system outright. Since delving into the unknown is always risky, most IT professionals attempt to do this work in as non-invasive a manner as possible through a process called “wrapping” the application, which is an approach to keeping the unknown as ‘contained’ as possible and interacting with it through a minimal, well-defined, and (hopefully) well-tested layer of software.

In all cases, the more a company understands about the application – or at least the portions that are going to be operated on – the less risky the operation becomes. This means not only unraveling how the application was first implemented (design), but also what it was supposed to do (features). This is essential if support for these features is to continue, or if they are to be extended or adjusted.

Updating Legacy Applications: A Formidable Task

What characterizes legacy applications is that the information relating to implementation and features isn’t complete, accurate, current, or in one place. Often it is missing altogether. Worse still, the documentation that does exist is often riddled with information from previous versions of the application that is no longer relevant and therefore misleading.

Other problems can plague legacy development, including the fact that the original designers often aren’t around; many of the changes made over the years haven’t been adequately documented; the application is based on older technologies – languages, middleware, interfaces, etc. – and the skill sets needed to work with these older technologies are no longer available.

Nonetheless, it is possible to minimize the risk of revising legacy applications by applying a methodical approach. Here are some steps to successful legacy updating:

 

Gather accurate information. The skills of a forensic detective are required to gain an understanding of a legacy application’s implementation and its purpose. This understanding is essential to reducing risk and to making development feasible. Understanding is achieved by identifying the possible sources of information, prioritizing them, filtering the relevant from the irrelevant, and piecing together a jigsaw puzzle that lays out the evolution of the application as it has grown and changed over time. This understanding then provides the basis for moving forward with the needed development.

In addition to the application and its source code, there are usually many other sources for background information, including user documentation and training materials, the users, regression test sets, execution traces, models or prototypes created for past development, old requirements specifications, contracts, and personal notes.

Certain sources can be better resources for providing the different types of information sought. For example, observing users of the system can be good for identifying the core functions but poor at finding infrequently used functions and the back-end data processing that’s being performed. Conversely, studying the source code is a good way to understand the data processing and algorithms being used. Together, these two techniques can help piece together the system’s features and what they are intended to accomplish. The downside is that these techniques are poor at identifying non-user-oriented functions.

The majority of tools whose purpose is to help with legacy application development have tended to focus on one source. Source code analyzers parse and analyze the source code and data stores in order to produce metrics and graphically depict the application’s structure from different views. Another group of tools focuses on monitoring transactions at interfaces in order to deduce the application’s behavior.

Adopt the appropriate mindset. While this information is useful, it usually provides a small portion of the information needed to significantly reduce the risk associated with legacy application development. A key pitfall of many development projects is not recognizing that there are two main “domains” in software development efforts: the “Problem Domain” and the “Solution Domain.”

Business clients and end users tend to think and talk in the Problem Domain where the focus is on features, while IT professionals tend to think and talk in the Solution Domain where the focus is on the products of development. Source code analysis and transaction monitoring tools focus only on the Solution Domain. In other words, they’re focused more on understanding how the legacy system was built rather than what it is intended to accomplish and why.

More recent and innovative solutions can handle the wide variety of sources required to develop a useful understanding and can extend this understanding from the Solution Domain up into the Problem Domain. This helps users understand a product’s features and allows them to map these features to business needs. It is like reconstructing an aircraft from its pieces following a crash in order to understand what happened.

Pull the puzzle together. The most advanced tools allow companies to create a model of the legacy application from the various pieces of information that the user has been able to gather. The model, or even portions of it, can be simulated to let the user and others analyze and validate that the legacy application has been represented correctly. This model then provides a basis for moving forward with enhancements or replacement.

The models created by these modern tools are a representation of (usually a portion of) the legacy application. In essence, the knowledge that was “trapped” in the legacy application has been extracted and represented in a model that can be manipulated to demonstrate the proposed changes to the application. The models will also allow for validation that any new development to the legacy application will support the new business need before an organization commits money and time in development.

Once the decision is made to proceed, many tools can generate the artifacts needed to build and test the application. Tools exist today that can generate complete workflow diagrams, simulations/prototypes, requirements, activity diagrams, documentation, and a complete set of well-formed tests automatically from the information gathered above.

Legacy Applications: Will They Become a Thing of the Past?

Current trends toward new software delivery models also show promise in alleviating many of the current problems with legacy applications. Traditional software delivery models require customers to purchase perpetual licenses and host the software in-house. Upgrades were significant events with expensive logistics required to “certify” new releases, to upgrade all user installations, to convert datasets to the new version, and to train users on all the new and changed features. As a result, upgrades did not happen very often, maybe once a year at most.

Software delivery models are evolving, however. Popular in some markets, like customer relationship management (CRM), Software as a Service (SaaS) allows users to subscribe to a service that is delivered online. The customer does not deal with issues of certification, installation and data conversion. In this model, the provider upgrades the application almost on a continual basis, often without the users even realizing it. The application seemingly just evolves in sync with the business and, hopefully, the issue of legacy applications will become a curious chapter in the history of computing. 

Tony Higgins is Vice-President of products at Blueprint. He can be reached at [email protected].

ITIL for BAs. Part VI; “Non-functional Requirements”

Written by Terry Longo on . Posted in Articles.

The two most recent posts about ITIL for BAs emphasized the roles of the IT Service, the Service Catalog, Service Level Management, and the Service Owner in encapsulating IT as a Service Provider.

It would be natural at this point to explore the ITIL/BA relationship from the Service life cycle point of view.  Much of both Service Strategy and Service Design address what are typically referred to as non-functional or supplemental requirements.  ITIL refers to them as Quality of Service (QoS) requirements.

Other BAs have rightfully pointed out (here is a good example) that QoS requirements frequently do not get the attention they deserve.  There are a number of contributing factors:

  • Stakeholders in QoS requirements are generally not the same as the functional requirements stakeholders
  • The negotiations involved in QoS requirements and functional requirements are different:
    • Functional requirements are normally negotiated by reconciling scope, schedule, and cost factors with development/test/release resources.
    • QoS requirements need to be negotiated by reconciling quality characteristics (availability, capacity, continuity, etc.) with IT infrastructure capabilities (assets), constraints (architecture), and even policy (especially in the area of information security management)
  • Elicitation techniques such as brainstorming, focus groups, interface identification, prototyping, requirements workshops, and reverse engineering are primarily used for functional requirements elicitation.
  • QoS requirements traceability is evasive; it’s one matter to trace the relationship between a function point in a software library to a step in a business process; it’s quite another matter to trace, say, the specific capacity characteristics of a particular IT component to the variety of business demands relying on that capacity.

It is also interesting to note that the BABOK addresses non-functional requirements most fully in Requirements Analysis rather than in Elicitation. 

ITIL’s coverage of QoS requirements is explicit, robust, and effective at contributing to deep business/IT integration.  This is evident particularly in the processes defined (Demand Management, Capacity Management, etc.), the extent to which those processes are embedded in the early stages of the IT Service life cycle, and the way in which ITIL defines “utility” (what the IT Service can do) and “warranty” (how well it does it) and then relates utility and warranty directly to their role in business strategy.  In my next post, we’ll cover that in more detail and then move into specific QoS-related processes and roles.

If you have any good stories to share about your BA experiences and the challenges around QoS requirements, please share them – your comments are great food for thought for your fellow BAs.

Meanwhile, Happy New Year to you and yours!