requirements – Page 2

Human OS, Stupid and Lazy, Leadership, Story Scope

Posted on October 28, 2011Leave a comment

Upgrade to the Human Operating System – BusinessWeek

I read this article, and it seemed to me to say for organizations in general, what Agile has done for software development teams. Moving from a command and control – process/factory model, to a model that allows/incents/expects humans to invent, analyze, innovate, figure out. Is it possible that we are finally ready to tranform organization structure from its industrial age roots into an information age – service orientation. How many organizations say “our people are our most valuable resource” – but act like they have FTE’s – (HR/Manager speak for “universal man widgets”).

Seth’s Blog: Stupid and lazy

I highly recommend that you evaluate every difficult thing that is on your plate, and decide whether it is lack of talent/skill/knowledge or simply lack of motivation that is getting in your way. I hate this evaluation, because it always comes out the same. Arrgh!

Seth’s Blog: The difference between management and leadership

This short post was a huge shot in the arm for me this week. Management is about constraints, leadership is about movement. Movement and constraint are opposing forces. Dang! Now that I am not in a staff management role (first time since ’04) this is much easier to see.

Stories, Epics and Themes | Mike Cohn’s Blog – Succeeding With Agile®

Mike Cohn is pretty much “the man” on user stories. I have had conversations with lots of agilists about stories epics and themes (story scope). What nobody (including Mike) really wants to get into is whether stories are about business capabilities or software capability. IMHO – when it comes to “requirements” for software – everything (not just agile) craps out on this divide. And it is a critical division because all the value is on one side, and all the work is on the other. Hmm. Never the less – I thought this was one of the best posts on story scope I have read in a long time.

Emergent Vs. Inverted Thinking

Posted on September 27, 2011Leave a comment

In agile communities developers, project managers, testers, there is a phobia or paranoia about big ANYTHING up front – that is we should not spend more energy up front than is absolutely needed to get the committed stories/features done in the next iteration.

The concept that we use is emergent thinking. Requirements emerge as we bootstrap our thinking by delivering early features. Design emerges, as we build features that have similar needs, and we refactor towards opportunities for generalization or re-use. Plans emerge as we estimate and sequence the stories in the backlog.

So what happens when the requirements don’t emerge. When the design doesn’t emerge. When it feels like we are just skating on the surface, because there is too much fear of bigger change, or spending energy building anything now because it will all change in 3 weeks. When the product owner is unable to sequence the backlog because there are unmade business strategy decisions that are inhibiting the emergence of plans, requirements, and designs.

I use inverted thinking. It is the opposite of big anything up front- I envision a result (it doesn’t have to be the right result) and I build a plan to acheive that result. I work backwards from a conclusion, as if my decisions were made. I propose a design (as thin as possible) that I think will support the envisioned result. I build a plan (as thin as possible) and propose needed skills and resources.

I pretend I know everything, and when I need an answer, I make one up. But every answer I make up, I list as a decision – because that is the schedule I want. What decisions need answers in what sequence, by what date, and what deliverables are dependent.

Then I dare every stakeholder to tell me why my proposal (that I just completely fabricated out of BS) is wrong. If you can’t give me a good reason not to do this, we are going to move forward in this direction.

When the fear of making a wrong decision is inhibiting the emergence of requirements, plans and designs – Invert the thinking from “What should we do?” to “Why shouldn’t we do this?”…

…and watch decisions emerge.

A Definition of Done

Posted on September 7, 2011Leave a comment

In his Herding Cats blog, Glen Alleman, asks a very pertinent question. What is the definition of done? Well?

Done (Enterprise software delivery project) – when software capabilities have been delivered that support the business value proposition per the customer’s business capability requirements.

In our agility, we recognize that requirements are clarified by “emerging information”. That doesn’t mean that they “change”. When a requirement “changes”, it is effectively a new requirement. We often experience a case where the business value proposition is inadequately defined at the outset of the project. In this case, it is necessary for this requirement to be clarified by emerging information.

We also recognize that there may be different paths to deliver different software capabilities that support a particular business value proposition. Chosing a different path or delivering different software capabilities that support the same value proposition does not mean the requirements have changed, more likely that we are responding to emerging information.

I like to break requirements into business capability requirements and software capability requirements. Regardless of your project methodology you must contend with these facts:

Fact: Enterprise software projects are created to deliver some business value. The requirements should define both the value (business capabilities) and a path to deliver it (software capabilities). Requirements form the basis of the definition of done.

Assertion: If the business value does not change, there is not a new requirement.
Assertion: If during the delivery of the business value, we learn things about the domain, the technology, or the world external to the domain that alter the path to deliver the value – there is not a new requirement – but emergent information.
Assertion: How we manage the (the documentation of our understanding of) requirements is a method.

Fact: Some software projects are required to change course mid-stream. Sometimes the business value we initially intended to deliver is overturned by market pressure, financial impact, or a change in management or strategy.

Assertion: When the business value for a project changes, there is a new requirement.
Assertion: When the work done toward that value is abandoned, there is a loss.
Assertion: How we manage the (documentation and accounting for) change to requirements is a method.

—
Recognizing that there is a difference between allowing emerging information to clarify, influence, or stabilize the delivery of value and accounting for changes in the definition of the value stream for a project is key to understanding agile and how agile methods manage both cases.
—

In either case, the definition of done is when we have delivered working software capabilities that support the business value proposition(s) that have been “commissioned” by the customer.

Units of Value

Posted on June 18, 2011Leave a comment

Planning a software development project is difficult. There are the typical issues: the changing face of technology, abstractions and generalizations, process maturity and resource competency. But none of this gets to the heart of why planning a software development project is difficult: because all of these things assume that the customer actually knows what they need and can articulate that need in a meaningful and comprehensible way; that the customer can describe the value that they want to get from the project when it is complete.

Depending on the methodology, analysts have constructed numerous abstractions to "organize" and "articulate" the value demanded by the customer. We call these "requirements". "features", "stories" – It really doesn't matter what you call them, as long as you recognize that they are the unit of value delivery around which you build your plan.

Your planning methodology (in conjunction with your software development methodology) must describe a way to turn these units of value into units of work. There are rules and assumptions that must be established about the content and structure of units of value that allow them to be converted into units of work. These assumptions and rule must be understood by analysts and customers who are defining the units of value, and by the technicians that are converting them into units of work. It is these rules and assumptions that allow your plan to accurately describe how you will deliver something of value to your customer, and allow you to communicate your progress towards the goal of that value delivery.

If you want to start somewhere to improve your software projects, start with defining the units of value, and the rules and assumptions necessary to convert them into units of work.

Semantic Clarity

Posted on March 19, 2011Leave a comment

One of the most difficult aspects of gathering and documenting software requirements is to get all of your stakeholders and project team participants to agree on terminology, especially words commonly used in the business domain. Common usage is never very precise, and often business problems arise from ambiguities in common usage. In developing a conceptual model of the business domain, it is necessary to define key metaphors very precisely, to remove these ambiguities, and allow software to implement logic that is correct.

There are two key types of metaphor ambiguities: semantic diversity and multiple identity.

Semantic Diversity – when a key metaphor has different properties in different contexts. This presents itself as a word that means different things in different aspects of the domain.

Multiple identity – when multiple metaphors actually share the same meaning or identity. This presents as different words that are used in different aspects of the domain to mean the exact same thing.

There is one other pattern that we see, which is called contextual revelation. Contextual revelation is when a metaphor presents different attributes in different aspects of the domain. In this case, it is the same metaphor, but different information is relevant to different parts of the business process. This often presents itself as if we have different metaphors, that have a mandatory one to one relationship with each other.

In some business domains, certain aspects appear optional, in that not all aspects are in play for every situation. In this case, the contextual revelation pattern may present as the metaphor having behavioral variants. In this case, one way of disambiguation is to derive the Behavior Taxonomy. Simply put, this can be accomplished by determining the simple list of behavioral variants that are needed to support the business process, and mapping the driver attribute(s) used in determining which behavior is selected.

100% SLA Requirements

Posted on February 10, 2011Leave a comment

Sometimes our customers fail to understand the complexity of modern
technology.

Our customer expects a system that NEVER fails to complete some critical
process. The problem is that when that critical process reaches a certain
level of complexity, and/or has a single point of failure this is not a
feasible requirement.

We all recognize that people are imperfect, and that all man made products
are imperfect. Computer hardware and software are imperfect, whether we
built it or bought it matters not. The 100% SLA is not a feasible
requirement because it assumes perfection that cannot be achieved.

Sometimes failures come because things outside a process change without our
knowledge. These events can happen without our awareness and the faster we
detect them, the faster we resolve.

If the customer needs to ensure that his business process completes 100% of
the time, then he should define requirements to “detect and inform” process
failures, to feed a backstop process that corrects them.

If these failures are frequent, he should perform root cause analysis to
create new requirements to “harden” the process against future failures of
the same root cause.

This model provides a path to correct and another to improve. These paths
lead to maturity and quality, a 100% SLA is a path to disappointment and
frustration.

Metaphors in Requirements

Posted on September 19, 2008Leave a comment

This week I was asked to review job descriptions for analyst roles within our IT function. The roles were “Analyst, Business Systems”, and “Senior Analyst, Business Systems”.

The person who asked me was looking for my opinion because I am strongly opinionated, blunt, and have experiencing hiring and leading business analysts and requirements engineers. She wanted to understand the difference between an analyst and a senior analyst.

Other than the expression of leadership within a project or team context that I would expect of any senior contributor, my answer had to do with metaphors.

Metaphors are the solid business abstractions that software is designed around. Metaphors are the unambiguously defined concepts that ground the business process. Metaphors are the litmus test to see if requirements are cohesive and complete. If your metaphors suck, so do your requirements.

Back in the ’90s when I was learning object oriented application design (OOAD) we were taught that each application or major feature had a “central object” that was the focus of it’s existence. Microsoft word has a “document”. Every e-mail client has a post or a message. This central object is the metaphor around which the application is designed, we just didn’t call them metaphors back then.

When designing an application all of your actions are performed on metaphors, all of your business rules contemplate metaphors, and your data model expresses your knowledge of your metaphors. Your metaphors are the essence of your understanding and modeling of the REAL BUSINESS stuff that your users and customers have to deal with in the REAL WORLD as part of their job. The more your metaphors align with reality, and the more you can eliminate ambiguity among and between metaphors in your requirements, the easier it will be for software designers, architects, and developers to model and fashion a system around them.

That’s my story and I am sticking to it. The senior analyst gets this, and carefully and thoughtfully identifies, defines, and clarifies essential metaphors within business requirements, and knows the the requirements aren’t complete until all of the metaphors defined hold together with the business rules and actions required.

Metaphors work most effectively when you can get your user community to communicate (to you, and to each other) in terms of metaphors that you helped define. When you have defined useful metaphors that clarify the business process, your users will adopt your terminology because it helps them understand what is important. Then in that context your software (being true to those metaphors) will be intuitive.

An analyst can capture and document the business process. The senior analyst (one with mastery) can change the conversation casting metaphors that help the business community define its value proposition and supporting processes more effectively.

Requirements Success Factors

Posted on September 13, 2008Leave a comment

Last January my role was redefined, and since then I have been managing two teams covering diverse aspects of two software programs. The first team is responsible for requirements, functional design, quality assurance, and the second team is responsible for support.

In this role, I have been focused on analysis and have been interviewing more business analyst type resources than I have before. I don’t call them business analysts, although my company has a job description for “senior analyst, business process”. The reason is because their job is not to analyze business process, their job is to elicit, understand, organize and document requirements for software products. I prefer to use the term “Requirements engineers”, and I like to talk about requirements engineering because requirements are not simply a description of the current or desired business practice, or a wish list. Requirements are a high cohesion document, describing capabilities that are required to deliver specific business value through software automation.

In a recent interview of a candidate for a contract “requirements engineer”, I asked a question that I usually ask candidates of any skillset – “What the top three critical success factors for practitioners of ?”

My friend Johanna Rothman would say that this is not a very good behavior description question, because it does not give the interviewee an opportunity to tell how he has done this. I believe that it is a very good question, because it asks two things at once? Does this candidate see him or herself as a practitioner of a discipline, or as someone doing a job. It also forces them to describe how they practice this skill set. If this answer rolls off of their tongue, then they have spent some time thinking about how to do a better job. If they struggle with it, it is likely that they don’t think about it much, they just do it.

Then there is the answer it self – this tells me what they think is important. I usually ask this question towards the end of the interview, after I have already asked the behavior description questions. I look for answers that are cohesive with the earlier responses, to see if they are spitting out what they think I want to hear, or they practice what they preach.

This candidate did pretty well – after he answered, he asked me what I thought the three critical success factors were.

My answer:

Semantic Clarity or Disambiguation – terms, and concepts, especially metaphors must be precisely defined.

Cohesion – the document must add up with mathematical precision.

Organization, especially abstraction or generalization – the basis of software is abstraction, and this must begin with requirements, classes of problems, value propositions must be clearly identified and categorized.

His answer:

He had cohesion and disambiguation or something close to it, but substituted scope management for organization.

I don’t think he is wrong, but in my organization, scope is fixed after requirements, not before. This is because premature scope management inhibits value delivery, IMO.

I think I’ll hire him…

— Correction —

My candidate did not have cohesion, he said communication, and he talked about making sure that each person walks away from a conversation with the same understanding of the topics discussed. I agree that this is a success factor for gathering requirements. Certainly anyone who goes into a business to understand what is required, in order to add some specific value to the business must have ample communication skills, and most importantly, establish appropriate feedback mechanisms to ensure that the understandings are shared. This for me is a component of semantic clarity and disambiguation, call it a sub-factor.