Requirements

Bad Requirement: It Must Be Good

One clear example of a bad software development requirement is the appearance of the word "good" within it. It will generally appear in the format of "the ____ must have a good ____". What is good vs. what is bad? Is coffee good for you? Does coffee make you smarter? How much intake of coffee is good, how much is bad and what is the relative impact between? How much coffee is enough to reach the threshold of good results?

In many cases, saying something should be good is an over simplification and doesn't provide enough granularity to be actionable by the individual that depends on the requirement to guide development. How about the age old debate between "good vs. evil". If you are a good dancer, does that also make you evil if a person believes that dancing is a sin? What about if you are alone and occasionally dance in the dark like the classic Bruce Springsteen song?

The point is that software developers and testers will have a difficult time making sure that a software deliverable meets a requirement that focuses upon being "good". The best they can do is make a subjective evaluation that if it appears to be "bad", then it likely would fail to be "good". 

EXAMPLE: The note taking portion of the application must be good in order to facilitate a proper determination on the outcome of the recorded case. 

In the above example, I would go directly to the source of the requirement and ask some clarifying questions about the note taking needs for recorded cases. This would involve both the ability to create notes and the ability to reference them when needed. Taking this forward, then we might be looking at some requirement refinement such as noted below. 

  • The user shall have the ability to log and view notes alongside case records.
  • The user shall have the ability to log and view notes in a separate window to the case being examined.
  • The users notes shall always be directly attached to the case being viewed when the note was created.
  • The system shall display a visual indication to the user if the case has attached notes.

All of the above requirements can be tested both from a functional and a usability perspective. When validating these requirements, the BA can ask the requirement source of there are any other characteristics they would associate with a "good" note taking experience for logged cases. 

© 2016 Dwayne Wright

Competing Expectations: The Project Manager & Business Analyst

The role of the business analyst is on the rise and often encroaches upon areas traditionally within the project managers domain. Although this conflict is actualized between those two roles, the root cause is generally found higher up in the organization chart. Both project managers and business analysts work very hard to meet the expectations of their superiors. Often it is the competing expectations that are causing the conflict and not a personality clash between the two roles.

SCOPE EXPECTATION MYTH FOR THE PROJECT MANAGER
When an organization places a project manager within a project, they are expecting that individual to deliver within the established budget and schedule. Simply put, project managers will manage scope creep because it is a legitimate threat to schedule and budget. A project manager that delivers a project within budget/schedule constraints with additional scope included is generally considered a great project manager. Yes, there are exceptions to this but not that many! In fact, unless that extra scope that gets squeezed into the project introduces new company risk, that project manager might expect a promotion for delivering more for less than expected.

MANAGING COSTS EXPECTATIONS DIFFERENT FOR A BA
A business analyst is expected to deliver significant value after the project closes. They identify areas in which more revenue can be returned or less costs incurred based upon value multipliers. A value multiplier would be the number of times the value can be triggered and the value amount. For example, a new feature saves an individual 2 minutes per use, it is used by 10,000 people at an average of twice per week. Exploring the value math, 

• triggered 20,000 per week (10,000 people x twice a week)
• 1,040,000 minutes per year (20,000 x 52 weeks)
• 17,300 hours per year (1,040,000 / 60)
• 70,000 average salary = $35 a hour
• $605,500 value annually (17,300 x 35)

The next steps a BA would perform include determining the costs of the new feature, perform a cost benefit analysis and associated payback period calculation.

If a business analyst wants to include an out of scope requirement in their package, it is because they feel the downstream value greatly exceeds the additional cost and project schedule impact. When a business analyst wants to submit a scope change request, the first obstacle they have to overcome is the project manager. Although a project manager should not have the authority to deny a change request submission, many will make the attempt to do so. They certainly should have a voice in the approval and I would recommend that all business analysts strive to have PM approval before submitting the request.  

EXPECTATION LEVELING
The key to avoiding or resolving this fundamental expectation gap is knowledge. At the fundamental layer, a project manager should not look at scope increase supported by the business analyst as a threat. In fact, any project that doesn't undergo some scope modification is generally an unhealthy anomaly. This is particularly true in software projects but it holds true for all projects. If a project looks to be adhering tightly to the scope identified in the early business case / charter documentation, then it is likely that dozens of a significant value opportunities are being lost. 

© 2016 Dwayne Wright