Skip to main content

Tag: Requirements

B.A.gile!

Written by Marcos Ferrer on . Posted in Articles. 1 Comment on B.A.gile!

This is NOT another Agile Methodology posting.  I make no claims to any special agile expertise, nor am I interested in methodology wars.  I just want to say that fads are fads, and never substitute for analysis.  I completely understand the attraction to agile.  It is an excellent summary of what can work for some teams, on some projects.

It is my observation that all the named methodologies I have run into can map onto BABOK concepts, and the BABOK is a superset of them.   

Here is the manifesto itself for context (derived from the Agile organization’s own web site at www.agilemanifesto.org ):

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

———————————————————————————

And here is one analysis, based on general knowledge, personal experience and BABOK concepts:

  • BA Fundamentals (and hence the essential skills to perform Requirements Communication) have to be present before tools matter.  Tools can only support competent, effective behavior, not create it.  In a sense, all successful projects are “agile” – it is my observation that all successful projects are full of brilliant individuals who interact fast and freely.  This single factor seems to compensate for everything else – counterexamples are welcome, I don’t have any.
  • Software over documentation is already the most common approach in software development, so it is hard to understand why it matters to “Agile”.  Since 65% “failure” rates are already being achieved in software development, it must be items 1, 3 and 4 that really matter, if Agile is effective at all.
  • Substitute “Iteration of Requirements with Stakeholders” for “Customer Collaboration”, and substitute “waterfall requirements” for “contract”.   Contracts, at their worst, are an attempt to “lock in requirements” before they are understood, leading to excess change order profits for the contractor (when changes are allowed), or failed stakeholder acceptance (when they are not).  Waterfall requirements are best saved for “one shot” efforts like the moon program.
  • Over planning, and reluctance to adjust plans as requirements are “learned”, is clearly a cause of certain project failures – it is mostly a failure of intelligence (see item 1).  What is missing from this concept is the idea of Enterprise Analysis (especially risk analysis, stakeholder analysis, and cost benefit analysis) and the Requirements Planning that must follow from these.  Another way to put this is – IF the project is simple and low risk enough, Agile may be a fit (see BOK tables 3.0 and 4.0 in the Enterprise Analysis section, and see if you can spot which projects might use Agile.

SO, from analysis to opinion (if you have your own opinion, send it in, we will tally responses and report on same):

IN MY OPINION:  Agile process fits certain kinds of projects, but hardly most.  Here is my list – what is yours?

“Small potatoes” – low risk, decent to high payback systems that only have to satisfy a small number of users with homogeneous interests, have low visibility, or represent proven, successful increments to already successful systems (yes, maintenance and enhancement).

 “Feasibility” or “Proof of Concept” trials, which could clear the way for more investment in a larger project?

 “Research” projects, where almost all is unknown, budgets are huge, and the paybacks considered indispensable, if they can be achieved at all.  These are really rare; one example was the “skunkworks” team that developed the unique (and ultimately unsustainable) Blackbird spy plane.

“Invention” projects for systems that can succeed “virally” and evolve, that represent completely new behaviors ,or huge boosters to behaviors, that people crave, regardless of how poorly delivered (e.g., cell phone service, social networking, 45rpm records).

WHAT AGILE PROBABLY DOESN”T DO is Enterprise level projects, projects that must organize the efforts of many people.  I am sorry to say that I hold this opinion in spite of the fact that I helped lead just such a success – an Investigation Management system for over 1400 government users.  We succeeded by using all four principles in the Agile Manifesto, AND this only worked because we were an A-1, Agile Item 1 team.

My advice – get the smartest team you can that actually CARES about their work, and put them under tremendous pressure – they will cut to the bone, and will NOT skip any critical steps, and you can call it Agile if you want, but I call it B.A.gile!

More shall be revealed. Keep the feedback coming to [email protected].

Have fun!

ITIL for BAs – Part VII; What Makes a Service Valuable?

Written by Terry Longo on . Posted in Articles. 1 Comment on ITIL for BAs – Part VII; What Makes a Service Valuable?

So much of a BA’s life revolves around functional requirements that the non-functional aka supplemental aka Quality of Service (QoS) requirements do not receive the necessary attention.

ITIL V3 defines the value of an IT Service as consisting of:

  1. Utility – the degree to which the service’s attributes have a positive effect on the execution of the customers’ tasks (e.g., steps in a business process), either by providing needed performance (functionality) or removing constraints; and
  2. Warranty – the robustness of the service with respect to availability, capacity, security, and continuity (that is, availability as a result of a catastrophic incident)

The diagram below depicts the relationships between warranty, utility, and their respective elements:

itilspart7_1.png

How useful is a service that is very fit for purpose but not fit for use?  The answer is that the service may have limited usefulness if its overall availability, security and responsiveness characteristics are either unpredictable or predictably very inconsistent.  What about a service that is highly available, secure and responsive, but does not offer the necessary functionality?  It is easier to see in this case the limited value, for the stakeholders’ primary interest is the solution’s functionality.

This model of a service’s value suggests:

  • Elicitation must address both sides of the “fit for use” questions – for example:
    • Not only “how available must the service be”, but also “what is the cost to the business when it is unavailable” and “what is the cost if we cannot recover the service quickly enough as the result of a catastrophic failure”
    • Not only how secure, but what are the costs and risks to the business without that level of security
    • Not only “what is the expected demand” but “what if the solution’s response time degrades with the specified demand parameters”
  • Full understanding of warranty requirements can only be gained relative to the stakeholders’ desired outcomes (this is in fact implied by the question “what are the costs/risks if the solution fails”).
  • Fit-for-use requirements are met through some combination of (a) the architecture that will accommodate the solution and (b) various design elements of the solution that are necessary to make up for deficiencies in the architecture relative to those fit-for-use requirements.
  • Early identification of fit-for-use requirements can help the solution team leverage as much as possible from the existing architecture and then include in the design only what is necessary to close any gap.

It is vitally important to capture the “costs and risks if it fails” for use by Service Owners and the IT support team once the solution is in operation, as that information is the basis for IT’s prioritization of pending Incidents.

As I noted in the previous post, the BABOK first takes on QoS requirements explicitly in the Requirements Analysis coverage (Chapter 6).  Hopefully you will interpret the above to mean that there is a lot of value in addressing those requirements (a) much earlier in the elicitation activities and (b) with the involvement of a core leadership team including the IT architect and lead software engineer (among others).

Here’s hoping that your 2009 is off to a great start!

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!

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!