Skip to main content

Tag: Best Practices

The Problem With Business Requirements: Series Wrap Up

There are high-level requirements, there are detail requirements, and then there is this in-between thing called business requirements.

The problem with business requirements is that they are allowed to be high-level, detailed or anything in between. As long as some business user says that they require it, the business analyst is duty bound to record it. The world (and business information system projects) would, in my opinion, be a much better place if there were no business requirements.

What I have found in my years of mentoring is that many BAs have trouble with the distinction between high-level and detail requirements. A primary objective of the Requirements In Context series that I just completed was intended to help make this distinction. This article is intended to be a summary of takeaway points from the series. Two of those points are:

  • High-level requirements should always have a business (and project) context
  • Detail requirements are most easily discovered when focusing on an HLR context.

Part 1 of the series introduced the need for improved requirements, presenting the classic ‘Swings’ cartoon as evidence that things do not appear to have improved much over the years when it comes to delivering business information systems. Part 2 talked about business functions as a context for high-level requirements. A generic functional view from 10,000 feet of an organization was presented as the ultimate business context. This generic business model was comprised of management functions, support functions, and line of business functions. High-level business functions were seen to act as a context for a number of business processes within that function. Each process, in turn, was seen to act a context for a set of business activities.

High-Level Requirements Guidelines

Part 3 of the series talked about project scope, and how scope statements and context diagrams can be excellent sources of HLRs. Examples were given of turning scope statements directly into high-level requirements. Part 4 provided guidelines for keeping high-level requirements high. It recommended that business analysts and project managers think of this exercise as ‘requirements planning’ rather than ‘gathering high-level requirements.’ What you definitely do NOT want to happen is for an HLR gathering session to degenerate into a business requirements gathering session.

Before diving into the subject of detail requirements, Part 5 of the series discussed four ‘build or buy’ delivery contexts (i.e. takeaway points):

  • Build – In-house with embedded SME (e.g. full Agile)
  • Build – In-house without embedded SME (e.g. Agile-like, Waterfall)
  • Buy – a custom-built solution (outsourced development)
  • Buy – a package solution (with optional customization)

It turns out that only the first of the above contexts allows for getting by without well-documented detail requirements. This is possible because with full Agile, the Scrum Team includes a business subject matter expert that is available full-time(ish). Performing the role of Product Owner, this person provides the necessary details just in time for each sprint.

Detail Requirement Form – User Story or Shall Statements?

I did my best in the series to stay out of the debate over the best form of requirement statements – User Stories or Shall Statements. At the end of the day, I believe that content is what’s most important, not form. Meanwhile, I will say that I like user stories. The main reason is that they have a clearly defined structure – a single sentence containing the elements who, what and why. Conversely, Shall statements just get the ball rolling with “The System shall …”. After that, it’s pretty much a free-for-all. A requirement in Shall statement form can be a single sentence, or it can run on for multiple pages. And don’t get me started on ‘shall’. I’ve actually never met a business analyst who likes the term in that context. The only thing worse (in my opinion) is replacing it with a term that implies the priority of the requirement. e.g. “The System must …”.

Detail Requirement Content – Seven Plus Or Minus Two

A detail requirement can be about a single attribute such as the ability to change the status of an order. Or it can be about a long list of attributes that are intended to be included in a screen or report. When there are a small number of fields involved (a rule I’ve always been partial to is “seven plus or minus two”), the content of the requirement can be contained within the user story or shall statement. The following example is taken from Part 5:

As the system I want to receive daily currency exchange rate data from the European Central Bank so that I can convert purchase amounts from a supplier currency to a customer’s preferred currency.
Acceptance Criteria
  • Given access to base exchange rates made available from European Central Bank
  • When the ECB exchange service makes new rates available
  • Then the following details about each currency is recorded and available for use converting between currency pairs:
    • To Currency e.g. USD
    • Effective Date
    • Exchange Rate From Euro e.g. 0.89
    • Rate Type e.g. Mid-Market

Note that in the above example the attributes involved ended up in the acceptance criteria. I consider this part of the requirement. If anyone has a good example of a user story that handles detail in the user story ‘sentence’ itself, please do share or describe it in an added comment below.
Conversely, I strongly recommend not trying to name long lists of attributes in a detail requirement. Instead, it should be possible to manage that amount of detail using a context-specific template. The following contexts are suggested as template candidates:

Each of the above context types includes a link to the series article discussing it along with an example detail requirement for the context. Here is one such example from Part 7. Again we see the acceptance criteria as a place to include a reference to where the appropriate full/complete requirement detail has been recorded:

The system shall display the details of the order that a customer placed on-line in response to the order having been submitted.
Acceptance Criteria – Order Completed Successfully
  • Given a customer placing an order on-line
  • When the customer has completed the order process including confirming the order
  • Then the details of that order are displayed as per the “Customer Order Confirmation Screen” specification found Appendix C.

The final context in the series is derived data. It’s discussed in Part 8. As with the context types listed above, simple derivations may be included within the requirement itself while more complex derivations might benefit from being described in supporting documentation referenced in the requirement statement.

Why So Much Detail?

As mentioned at the beginning, business requirements that contain only ‘middle of the road’ detail serve little purpose. Designers, developers, and testers don’t have sufficient information to do their jobs in three of the four delivery contexts listed. When additional detail is needed (and it certainly will be) either a business SME will need to be contacted, or else the project ends up being yet another casualty of The Swings.’

Making use of context-specific templates can help guide BAs to record sufficient detail to deliver each of those items ‘in context’ for the project, based on HLRs that identify them. And with this level of detail business information systems can be built that (hopefully) satisfy the business needs.
So, as promised – takeaway points from the Requirements In Context series:

  • High-level requirements can be sourced (partially) from project scope and context diagrams
  • Keep high-level requirements high level
  • Detail Requirements are most easily found within an HLR context
  • Detail requirements should be fully detailed (not just listed), using context-specific templates when needed

And a bonus takeaway point introduced in this summary article:

  • Avoid producing Business Requirements

Using Scope Models to Manage Solution Scope

Organizations launch change initiatives (projects) for the purpose of delivering a benefit to the organization.

One thing that may cause those change initiatives not to deliver those expected benefits is scope creep. Scope creep is the unexpected and uncontrolled expansion of a project’s scope. This can occur when the scope of a project is not properly defined, documented, or controlled. Scope creep generally negatively impacts the project’s budget and/or schedule. Increasing project scope can also increase solution scope.

scopecreep

One way of defining and documenting solution scope is by the use of scope models. I do caution that this is not the only way of documenting solution scope, and multiple ways of defining and documenting scope should be used for every change initiative undertaken. Solution scope should be defined and documented in the way that allows the project stakeholders to understand the scope. Scope Models should create a shared vision of the solution scope amongst the stakeholders.
I am going to show you six scope models I use. There are definitely more models that can be used as scope models, but I find these to be the ones I use the most. Which models you use depends on the type of change initiative you are undertaking and what will describe the solution scope to the stakeholders the best.

Related Article: Using Feature Trees to Depict Scope

A Functional Decomposition depicts a subject and the breakdown of that subject into smaller buckets. This breakdown can be in multiple levels; meaning break down the subject into the highest level components, then break down those components into small components. This can be done to three or four levels. Functional Decomposition can be done on a feature basis or work basis. Using the feature basis, you would take a system and break it down to its highest level functions, as shown below. Using the work basis, you would take a work initiative and break it down to its highest level pieces of work; then break each of those pieces of work down to smaller chunks of work. This is useful to create a work breakdown structure and estimating work effort.

scopecreep2

The Context Diagram depicts the system that is under discovery, the focus of your change initiative, and the external entities that interact with that system. These external entities can be systems, databases, websites, or business units (people). This model also identifies the data flowing between the external entities and the system under discovery, and depicts the direction of flow for each piece of data. One limitation of this model is that in only depicts external entities that directly interacts with the system under discovery.

scopecreep3

A Process Flow illustrates high-level processes and the entities involved in those processes. A common process flow diagram is called a swimlane diagram. The swimlane diagram shows processes in a row, or lane, entitled by the entity that performs those processes. Several lanes are depicted in a swimlane diagram so that you can see the interactions and dependencies within the process, as shown below.

scopecreep4

A Use Case Diagram is a representation of a user’s interaction with a system that shows the relationship between and the different use cases (functions) in which the user is involved. A use case diagram can identify the different types of users of a system and the different functions those users perform using the system.

scopecreep5

An Ecosystem Map shows the system under discovery and the systems which send data to or receives data from that system. The major difference between this model and a context diagram is that the ecosystem map will show systems that do not interact directly with the system under discovery; that is upstream and downstream systems. As shown below, a website order entry system sends the customer order to the order fulfillment system, which sends product data to inventory system and purchasing system. The inventory system sends the inventory transactions to the accounting system. The accounting system also receives purchasing transactions from the purchasing system. Even though the order fulfillment system doesn’t interact directly with the accounting system they are both exist in the ecosystem; and therefore, are shown on the ecosystem map. The system(s) under discovery will be shown with a bolder outline than the other systems in the ecosystem map.

scopecreep6

The Feature Tree is a fishbone diagram showing the features within the system. Much like the functional decomposition, the feature tree breaks higher level features into lower level features. Level 1 (L1) features are the highest level features and branch off the horizontal line of the diagram. Level 2 (L2) features are lower level features which branch off the L1 features. There is no reason to go beyond three levels of features. You can use color coding of the features to show what is in scope, out of scope or features in future releases. This is an excellent model to show executives, as it is a very easy picture that allows for a very quick understanding of the features being looked into.

scopecreep7

It may be necessary to use multiple scope models to ensure that all stakeholders understand the solution scope of the change initiative. By using these scope models, as changes to scope are suggested you can determine if the change being requested is within the model. If it is not, you can caution the stakeholders that this may cause scope creep that will impact the project scheduled and/or budget.

Requirements in Context Part 8: Derived Data

It’s the job of Business Information Systems to know stuff. They are able to know stuff either because they have been told the stuff or because they have been told how to derive stuff from the stuff they know.

This article is about deriving stuff within the context of detail functional requirements.

Contexts For Derived Data

In parts 5 and 7 of this series we saw three detail requirements contexts that can involve derived data:

  • Interfaces
  • Reports
  • On-Line User Interfaces

There is a fourth context not yet discussed – Internal Processes.

Content Detail for Internal Process Requirements

An internal process is a cross between a report and an input interface. It’s like a report in that it runs at a scheduled time and has selection criteria that finds all of the records it needs to work with. Having been initiated and with the selected records the internal process behaves like an input interface, working its way through those records with the result being new records inserted into the database and/or existing database records updated.

An example of an internal process for a Banking Information System might be “Credit Customer Accounts With Earned Interest.” Scheduled to execute daily, the process would:

  • Find all of the Customer accounts that are due to be paid interest.
  • For each account found
    • Look up the rate of interest that applies to the account type
    • Calculate the amount of interest earned
    • Create a credit transaction for the customer containing this amount
    • Post the transaction (resulting in the account balance being updated with the interest amount)

A detail requirement for the “Earned Interest” internal process would follow the same pattern as for reports and interfaces described in Part 5 – a single detail requirement that names the process and references its details recorded in an Internal Process Spec. The drafting of this requirement either as a User Story or Shall Statement is left as an exercise for the reader (pick your preferred format). Extra credit will be given for including acceptance criteria.

As indicated in the previous articles, the detail requirement does not mention each field involved. Rather the detail, including identifying individual fields involved, is relegated to a template-based specification appropriate each of the context types. In cases where a field represents derived data, a description of the derivation should be included as a comment associated with the field. We will see examples of these below.

Data Derivation Descriptions

I like to think of derived data, and their corresponding descriptions as being one of the following three types:

  • Grown Locally
  • Phone a Friend
  • Build an Ark

Grown Locally – With this type of derivation, the values needed for the derivation can be found amongst the other fields in the spec for the given context. So when you are describing the derivation, you are referencing fields that are listed right there in the spec.

Example 1 – Producing an Invoice, the query has returned all of the line items being included in the report. Each Line Item includes the “Total Amount” for that line. So when it comes time to derive the overall “Invoice Total” field value the necessary items to sum up are all available. If the invoice can involve additional fees or charges, then the derivation would involve them as well.

Given fields called “Line Item Total” and “Shipping Charge” listed in the report spec, the derivation description in the comments field for “Invoice Total” might be:

Sum of Line Item Total values plus Shipping Charge

This description is a verbal version of a mathematical formula. The equivalent mathematical version would look something like this:

Invoice Total = Sum(Line Item Total) + Shipping Charge

In cases where a derivation formula involves lots of fields and/or more complex calculations it can be clearer to use abbreviations:

LIT = Line Item Total, SC = Shipping Charge
Invoice Total = Sum(LIT) + SC

NOTE: I’ve kept the example that uses abbreviations the same as the previous two forms. It would probably not be necessary to resort to this style until the number of fields or the complexity of the formula gets larger. When you encounter these, you’ll recognize the benefit of using both the mathematical form and abbreviations.

Example 2 – Presenting Customer Name on a report or screen as a single field derived by stringing together the locally available non-derived fields Title, First Name and Last Name. The derivation description in the comments field might be one or the other of the following:

Customer Name is a concatenation of Title, First Name and Last Name. E.g. Mr. Fred Smith
Customer Name = Title + [space] + First Name + [space] + Last Name E.g. Mr. Fred Smith

Derivation descriptions should include examples wherever possible. Examples help confirm what the business is wanting and provide guidance for development and testing. Note that both description versions in Example 2 expect there to be spaces between the concatenated fields. The first description didn’t mention anything about spaces, but the included example showed that spaces were part of the derived result. The second description indicated spaces explicitly. Even so, an example is worth including.

Both Example 1 and 2 above involve simple formulas describing how to derive a field from existing data using arithmetic operators or via string manipulation. Derivations can also involve logical operators such as greater than, equal to and less than either as simple pairs or combined with And, Or and Not. The following variation on Example 2 involves a single condition. The additional fields are assumed to be ‘grown locally’ as well:

Example 3 – Presenting either a Person Name or an Organisation Name depending on Customer Type:

If Customer Type is equal to “Person” then Customer Name is a concatenation of Title, First Name and Last Name
Otherwise, Customer Name is Organisation Name. E.g. ‘Starbucks’, ‘Mr. Fred Smith’

Phone a Friend – This type of derivation involves one or more values that are not amongst the fields in the context. They need to be sourced from the information system’s database.

Example – Grocery item purchases being captured using an on-line POS terminal. Scanning the barcode of each item identifies the product but the “Current Unit Price” needs to be looked up. The derivation description in the comment for this field might be:

Use the product’s BarCode and the current date/time to find the Product’s Current Unit Price

Note that his description is very ‘what, not how.’ No mention is made of what table contains the field that will have the value needed. Those details should be left to the solution designers. The derivation description is best left to what the business knows at the time the derived value is needed. If it turns out that additional details are required to find a result, then the SME should provide the correct information for the BA to include in the description.

Data derivations can be a mixture of Grown Locally and Phone a Friend. If a derivation formula involves one or more fields that require lookup, then the description might best be split into multiple steps. The Phone a Friend steps should be described first so that the values become available. They can then be used as if they were ‘local’ in the remainder of the derivation.

Build an Ark – When derivations go much beyond a simple formula, a small number of database lookups and/or conditions the form of the derivation is called an algorithm. The comment field of a detail requirement spec is not an appropriate place to describe an algorithm. It really needs its own separate specification [template] and its own [single] requirement.

Content Detail For Algorithm Requirements

Algorithms will typically have a business activity name such as “Determine Price” or “Determine Eligibility”. This activity would very likely appear as its own ‘box’ in at least one business workflow. Descriptions of algorithms fall into the category of ‘A picture is worth a thousand words.’ In this case, that means providing something like a UML Activity diagram. Those types of diagrams are designed to show sequences of steps and branches based on decision points (i.e. conditions). The pre-UML name for an Activity diagram is “Flow Chart.” The diagram (and supporting text and definition of fields used) represents the details of the functional requirement.

Like the contexts discussed previously, a single requirement should be used to represent the detail. An example based on our ‘pricing’ activity would be as follows:

User Story Format:

As a Customer, I want my contracted rates used when pricing purchases because those rates are legally binding during the term of my contract.

Shall Statement Format:

The system shall use the currently contracted rates for a customer when calculating the price for purchases made by that customer.

Both requirements should include acceptance criteria:

Acceptance Criteria

  • Given the current contracted rates for a customer
  • When the customer purchases a product
  • Then the price charged for that product is the result of those rates being applied to the “Customer Pricing” algorithm described in Appendix C.

The activity diagram and accompanying description are produced by the BA in conjunction with the SME that understands the algorithm. Some of the fields involved will be ‘locally grown’ and some will involve ‘phone a friend’.

Requirements In Context – Just Know It

This series has been about business information systems and how it is their responsibility to know what users need to know to support their business processes and activities. What the system ultimately knows is field-level detail. This detail is sourced from input interfaces, on-line interfaces, internal processes, and algorithms. Providing that detail to users and other systems is through reports, output interfaces, and on-line user interfaces. Detail requirements, at the end of the day, is about field level details in context.

The next and final article will summarise the key ‘take-away’ points from the series. Following that, there will be a quiz.

What Is the Lifecycle of a Requirement?

In a traditional IT environment, requirements are created at the beginning, handed down the process, and validated at the end. In an Agile IT environment, requirements represent working software and are created, refined, and revised in a circular process.

So, what does that requirement lifecycle look like in an Agile environment?

Related Article: User Stories & Mousetraps: A Lifecycle of Conversations

vineyardJuly

1) Build the Right Thing

The first step is to identify why we are doing something. Stakeholders come to us with their identified problems. However, it is up to the business analyst to probe for the root cause, the business value desired, and the innovative solution.

For example, a homeowner requests new hardwood floors so they look like the day the house was new. We need to know if the customer wants new floors for $12,000 or to refinish the existing floors at $4,000.

Second, we determine who is using our product. We want to know who is our audience, what matters to them, and how we get their feedback. We can use techniques such as story mapping.

Third, turn key features into requirements that deliver customer value. Once we understand the Why and the Who, we align our feature requirements based on the value it delivers. In this way, we ensure all feature development delivers value, and we reduce the likelihood of waste.

2) Build the Thing Right

Once we’ve determined the right thing, we begin the process of building the thing right. The requirement lifecycle continues to get as independent, small, and testable as possible. This example demonstrates the refinement process.

Vertically slice your requirements to create stand alone, customer-value-driven requirements – not architecture-oriented, stack-oriented, or data-oriented.
  Start: I need a form which collects the number of family members for one unit.
New:
I need to calculate the total number of family members based on number of adults and dependents.
Progressively elaborate further using INVEST   New:
I need to collect the number of adults within a family.
I need to collect the number of dependents within a family.
Break down these requirements into user stories.   For total number of adults:
As a client manager, I want to sum the number of adults based on date of birth in a family so that I can report accurate information to funding organizations.
Add objective, measurable, testable acceptance criteria to measure when the criteria is satisfied.   Acceptance Criteria:
– Must be a whole, positive number
– Must be larger than zero

3) Gather feedback

The lifecycle leads you through the process back to the beginning. You need to collect customer feedback once you’ve implemented an independent, small, testable feature.

At this stage, measure how your customers or clients use the features. Compare results with your goals and objectives identified in your Product Vision. Revisit “Build the Right Thing”. Did you get it right? What do you need to change? What do you need to add?

4 Prototyping Myths and Mistakes a Business Analyst Should Avoid

You live and you learn.
Make better mistakes tomorrow.
Fail faster.

Yes, to err is human. When done right, it’s also an important part of defining and designing great software. From conceptualization to final delivery, you’re likely to design and redesign your ideas countless times using some combination of wireframes, prototypes, and mockups. These tools allow you to translate text requirements into visual ideas, explore them quickly, and correct mistakes early before they get too deeply embedded in your designs and are too costly to fix.

Related Article: Bring Your Requirements Practices out of the 80s

Here’s a brief look at the similarities and differences between wireframes, mockups, and prototypes, and four mistakes to avoid when using them on your project.

Streamlining your design process

One of the best things teams can do early in a project is to level-set about what documents will be used, and what type of information each is meant to convey, so that stakeholders, designers, and developers share the same expectation about when they’ll review the structure and function of a website or application.

Let’s start with wireframes. They’re like the blueprint of a building. Although high-fidelity wireframes are used, most tend to be low- to medium-fidelity schematics that help you understand the layout and arrangement of all the things that must fit into the space. They’re quick to produce and share, and help teams focus on big picture basics versus detailed design elements. But a blueprint is not a house. As a static image, a wireframe won’t let you see how the thing you’re designing would fare when used by a human.

Mockups are a little harder to define because they often mean different things to different people. I’ve seen the term used for something that resembled a lo-fi wireframe, but also used for something much higher fidelity that resembled the final product. That said, the term is most often used for something that takes wireframes a step further, possibly adding color, type choices, images, and even functionality.

That’s where prototypes come in. They’re a powerful medium for testing perspectives and interactions–all the things that make the product really work. Since they’re meant as a testing device, having some detail makes sense to give users context.

Agreeing on how these tools are used in the design process helps us dismantle our first mistake:

Mistake #1: Treating them exclusively as a design tool

It’s a mistake to think that wireframes, mockups, and prototypes, should only document the contributions of someone whose title includes the term “designer.” Hold on, though. Before you get your pitchforks and torches, let’s be clear about what we’re saying. Text-based BRDs still have their place. And maybe that place is a bit closer to the design than it’s been in the past.

The most innovative companies in the world understand that design is a verb, not a noun. It’s not about creating design documents. It’s about designing a process that’s participatory and collaborative.

Couldn’t you say that a business analyst who is eliciting requirements is starting the design process? How about a developer who’s thinking about the script for a page load indicator? Neither fits neatly into traditional concepts of design, but they’re each crucial to the end result.

When designs miss their mark, it’s not necessarily because you have bad designers or business analysts on the team, or that your user stories were poorly written. It’s more likely that there was a communication breakdown somewhere in the line. Finding ways to integrate documentation is a way of approaching the human-centered design process so that it benefits not only the end user but also your project team.

Think about the value of facilitating collaboration and communication by allowing teams to view comments, annotations, and requirements in the same screen as the designs. It’s social and synchronous and eliminates a lot of the errors of passing documents back and forth and hoping details don’t slip through the cracks or get misinterpreted by other team members.

Mistake #2: Believing You Have To Give Up Speed Or Detail

As the old project management joke goes, when creating a project, clients can choose to have it done fast, good, or cheap. But they only get to pick two. The notion being that to get a project done fast you’d have to give up detail and accuracy. On the flip side, nailing down the details would take a long time and come at a pretty hefty cost.

The mistake in this scenario is overlooking the flexibility teams have in how much detail they’ll provide in each deliverable and at each stage of the design process. It also ignores the relatively new tools now available. Wireframes, mockups, and prototypes can work to help quickly define the layout and function of the application. The impact that these visual and interactive tools have on speed and detail can’t be overstated.

Which deliverable is most useful depends on your project and the problems you’re trying to solve. We’ve all used rudimentary wireframes to get through initiation, or rapid prototyping to walk through user flows, drive analysis, and find functional gaps. As more teams adopt Agile and Lean methodologies, it makes sense that the tools driving requirements, user stories, and design should evolve too.

When teams can use visually interactive tools, collaborate, iterate quickly, validate and build consensus, you’re actually able to get both more speed and detail.

Mistake #3: Focusing on the outcome instead of the process

It’s common for teams to concentrate mistakenly on using wireframes and prototypes to problem solve on already decided upon directions and ignore the value these tools offer in ensuring the right questions are being asked before answers are agreed on.

The danger in focusing too intensely on finding solutions is that it locks you into a certain way of thinking. That’s the opposite of innovation. In building any software application, you’ll find that using the right design tool can elicit requirements that hadn’t been thought of yet, and expand the number of opportunities for finding the simplest and best approach.

Rather than schedule reviews featuring big reveals, teams should embrace opportunities to walk through designs and requirements together and ask things like, “How would you expect this to work?” or “Where is the user taken after they click this button?”

The future of collaboration needs to include integrated environments where wireframing or rapid prototyping can happen in the context of mapped requirements, comments, and annotations–not separate from them. This approach holds the promise of stanching inefficient practices like blind handoffs that lead to broad interpretation or worse, back-and-forth email discussions that block progress or broaden the scope.

Reviews that include the right stakeholders and focus critique to specific problems tend to stay focused, productive, and on track. When all of that happens in the context of the design itself, it will help you identify problems and definitions as well as iterate ideas and test their validity. In short, you’ll get better answers, faster.

Mistake #4 – Elevating aesthetics over annotation and agreement

Better design does not mean most viewed on Dribble. As design programs continue to proliferate and become increasingly specialized and fine-tuned for UI design, it can be tempting for talented designers to spend hours nudging pixels to get a layout just right. But to what end?

Great design is as much about user interaction as it is about pixel perfection. Spend the time finding the right cadence to design, review, test and repeat.

Find a tool that allows you to review designs together, elicit feedback, and iterate on what you’ve heard in real-time. If they can integrate with your existing ecosystem, allowing communication and traceability with the tools the rest of your teams use, even better. This allows timelines to be adjusted immediately. If you’ve ever worked on a distributed team, you know the value of having teams work in unison and how hard it can be to implement.

Use prototypes as visual expressions of text requirements that help business stakeholders and development teams gain consensus on whether or not business and functional requirements have been met.

And keep in mind that the heart of consensus is a based on a cooperative process where everyone’s input is carefully considered to craft the best outcome. The more methods you use to compile and summarize that input, the harder it is to synthesize the information you’ve gathered into a solution that represents a commonly agreed and accepted set of features and functions for your release.

Getting to a single source of the truth

When one team owns requirements, another design, and a third workflow and timeline documents, it’s hard to agree on where you are or what to do next. Current design tools only exacerbate the problem, focusing on rendering images without providing enough context or connection to other project documentation. Lack of requirements integration is truly an Achilles heel of today’s software design process.

As the Agile Manifesto alludes, the primary issue with communication is one of understanding, not of documentation. The best approach to avoiding the common mistakes listed here is to base collaboration, not around documents that merely reflect design decisions, but around shared communication tools that offer teams a single source of “truth” to rally behind and shape decisions on.