Category Archives: Austin TX

Posts related to Austin, TX.

Intro to Requirements Gathering – St. Edward’s University

St Edward's logo

Welcome Dr. Franke’s students in Analysis, Modeling and Design MCIS6310! Thanks again for inviting me to present to your class on requirements gathering and requirements management.

The presentation is available for download. You can get both the slides and the notes pages. The notes pages include additional content and links to articles for further reading on the individual topics.

For the rest of our readers – the presentation for the St. Edward’s class is primarily written for people with little exposure to formal requirements management processes. It does not go into the depth of most of our articles, and instead hopes to present a broad overview of what we do when managing and developing requirements.  The presentation is 34 pages (about 90 minutes speaking time)
If you’ve been reading Tyner Blain for the last few months, there is little new material. If you’re new to Tyner Blain, the presentation is worth a quick read. Although we didn’t record the presentation, the notes-pages will provide some additional context to the slides.

Requirements Management Software Will Not Solve the Problem

Norm Abram

Requirements management software will not solve our requirements problems.

Jerry Aubin of Seilevel made this great point in his presentation this evening at the IEEE Computer Society, Austin / A-SPIN event. This was a great event, focusing on how to take requirements management “to the next level” – not just being good at it, but being great at it. Seilevel’s speakers (Jerry and Joe Shideler) demonstrated that they have great insights into the art and science of requirements management – and presented some cutting edge ideas that extend the “known good ideas” in some interesting directions. Definitely a company to keep our eyes on and learn from. Their blog, requirements defined, is linked in our blog roll – check it out.

The Norm Abram analogy

Jerry used what he coins as the “Norm Abram analogy”. Norm Abram is a great carpenter, and he does a weekly television show here in the US. He has an amazing workshop, with every tool imaginable for cutting, shaping, sanding or finishing wood. And Norm uses those tools to create beautiful products.

If you had those tools, Jerry asked us, would you be able to suddenly create products as beautiful as Norm does?

No.

Norm became a great carpenter and he became proficient with tools that help him do his work faster. The tools didn’t make him better, they just make it easier for him to do the work.

Would having typewriters make us write better, or just faster?

Applied to requirements management

The same holds true about requirements management software. Having access to software won’t make us better at managing requirements. The software will help someone who already knows how to manage requirements be more efficient.

The folks at Seilevel have seen the introduction of RM software (requirements management software) actually be counter-productive for teams who are new to managing requirements. We agree – we think it’s like getting an expensive car so that we can teach someone how to drive. The learning process has to come first.

Jerry showed statistics from the Standish Group’s 2004 CHAOS report. We’ve talked about that report earlier. That report shows that 71% of software projects fail. The issue isn’t the speed or cost of writing requirements, the issue is writing bad requirements.

For those 71% – the problem isn’t the tool, it’s the training. For the other 29%, there are absolutely solutions to help us do our jobs faster.

What should we do?

There are two ways to get better requirements. Buying RM software is neither one of those.

  1. Get help with your requirements. Companies like Seilevel and Tyner Blain have already invested in learning how to do requirements right. Let them or someone else help you manage requirements, or let them do it for you.
  2. Learn how to manage your requirements. Get training, read, study, practice, fail, improve, and succeed. As individuals, find mentors. As companies – get outside experts to come in and audit your projects.

When should we buy RM software?

When we’re already good at writing and managing requirements, and we’re looking for a cost reduction. Introducing a tool of this complexity to a team that isn’t accustomed to the process will actually hinder the process.

Requirements vs Design – Which is Which and Why?

faceoff

Requirements versus design – which is what, when and why?

A classic debate. It comes up often. Unfortunately, it’s a source of confusion that causes many teams to shy away from staffing, creating, or managing any formal requirements processes. There’s a discussion on Seilevel’s forum where this has been brought up again, and it’s shaping up to be a fine grudge match here in Austin. Thanks to Cauvin for calling it to our attention. We can’t let the other folks have all the fun, so we’ll chime in too.

We’ve described the software development process before as being like an onion – having multiple layers of abstraction within which you describe the problem and solution. In this post we will translate that perspective into “what is a requirement” and “what is design”.

The layers of abstraction

  1. Market requirements. The problems or opportunities that express potential ROI opportunities. These can be captured in an MRD.
  2. Product requirements. In a process that uses structured requirements, these are the functional requirements, user requirements and business requirements. Design constraints are also requirements (non-functional requirements). Product requirements can be captured in an FRS, SRS, or PRD.
  3. Solution design. The architectural description of the implementation, UI and test suite. Design decisions define much of the reality for developers – good design decisions make implementation and maintenance easy. Bad design decisions can make for disaster.
  4. Implementation. The actual code that is written and running. The user interface that is presented. The tests that are included in a regression suite. We do what we’re asked, in the way that we’re asked.

The point of contention

The debate is over the classification of product requirements. In this post we’ll talk about the red team and the blue team, much like the foosball players in the image above. We’ll also use one of the examples presented in the forum as the anecdote for describing our perspective. I want to avoid putting words in other people’s mouths, so I will hilight my interpretations as being just that. And as interpretations, they may very well be wrong.

My interpretation is that the blue team believes that market requirements are the requirements, and any further specificity should be classified as design (also this). My interpretation is that the red team agrees with what we’ll write in the rest of this post.

A red team quote:

My philosophy on this is simple. If the business or the business users care about it, it is a requirement.

That being said, the business often times cares or wants things that they shouldn’t care about or want, so they do have to be careful not to demand things that truly arent requirements.

An unambiguous description of requirements and design

There is a middle ground between market requirements and design. There is a step in the software development process that happens between “defining the problem” and “designing the solution.”

mrd to prd

When talking about market requirements, we describe the problems and opportunities that define the space. A great place to document our insight into the market is in a market requirements document, or MRD. In this hypothetical example, our mythical company is losing customers because they have to wait too long when they are on the phone to get support.

There is an ideation step, where we perform an analysis – as engineers, we would call this a root cause analysis, where we identify why the customers make software decisions based on support-call length, why the call lengths are long, etc. After we identify the root causes, we determine which ones are properly addressed with software, versus process, project, expectation setting or any other solution.

Our mythical company has decided that there will be a software component to the solution, and it will have the goal of reducing support call times.

The instant we decide that this problem is going to be solved with software, it becomes a software product requirement. And a great place to record that information is in a product requirements document, or PRD. We talk more about this in our post, From MRD to PRD – the key to defining a spec. And this is the source of our disagreement with the red team – we believe that these are both requirements, they are distinct, and they should coexist – and still both be labeled as requirements.

prd is structured

At Tyner Blain, we strongly support the use of structured requirements as a means of capturing, managing, and communicating our software product requirements. We start with the GOAL of reducing the average support call time. We define the use cases that capture the support-call process (or story, or scenario – if that’s your term du jour). We articulate the functional requirements (sales rep can find the customer records for the customer on the phone). And we define the design constraints, or non-functional requirements.

This is where we think we agree with the blue team as long as we add the following clarifications. Design constraints are requirements. When our client expresses the need to conform to a corporate look and feel – that’s a constraint. When we describe support for color-blind users – it’s also a constraint (although it is an ambiguous requirement without supporting material or cross-domain experts on the team). Any time we define performance characteristics (search must happen in five seconds), it is a constraint.

In all these cases, we require the software developers to design a solution within the bounds of our constraints. Constraints are requirements.

prd to design

The implementation team will design (and later develop and test) a solution based upon the requirements. The requirements include constraints on how the implementors are allowed to design and implement.

Where we disagree with the red team

While generally agreeing with the red team (that requirements do exist between markets and designs), there is one statement where we do disagree.

Red team:

If I specify that the support rep must be able to search by last name, partial names, customer ids, address, phone number etc. Is that requirements or design?

Lets say you can agree that the above are requirements

[…]

Are all of those things design? I think it depends on the capabilities of your teams.

We disagree – we believe that these implementation details (by what fields a user should be able to search – and, in fact, specifying that search is the implementation approach) are not part of requirements – they are part of design.

I understand how easy it is to let project realities affect the classification of some design elements as product requirements. I’ve personally made the mistake of taking that perspective to extremes in the past.

Defining details like this (what, exactly, does the software do) are design decisions. Irrespective of the capabilities of the teams, these are design steps. It may be, for a given team, that the product or requirements manager has to help a particular software designer to make good decisions. But that doesn’t make those suggestions into requirements – it just means that the RM is helping with design. And those details would belong in a design document. Yes it’s more convenient for a product manager to put those details into the PRD, but they don’t belong there.

Summary

In conclusion – there is a natural flow from market opportunities to product requirements to design decisions in the state of all value-driven software development projects. These three concepts are distinct. They should be documented distinctly. We suggest using an MRD, a PRD, and a design document. As a simple checklist, think of each idea in this way:

  • Am I describing an opportunity and it’s relative value? MRD
  • Am I defining a particular opportunity that we’ve agreed to solve with software? PRD
  • Am I describing the implementation of the solution? Design Document

Please join in on the discussion – if not here, then at the forum or on Cauvin’s blog.

iRise – software prototyping tool

irise logo

We received a comment from Tom Humbarger at iRise on an earlier post, which led us to take a look at their site.

iRise provides a tool for rapid prototyping of web-based applications, and there’s an overview of the products available. They have iRise Studio which allows people to create interactive prototypes of web-based applications, and iRise Reader that allows people to interact with their prototypes.

This is a good news, bad news, good news (at the end) situation.

The good news – they have an innovative idea – use prototypes to communicate requirements.

The bad news – Our initial excitement about their product quickly turned to skepticism while reading their copy…

Who are the target users?

iRise Studio is a powerful, easy-to- use application definition solution used by business experts to quickly assemble functionally rich simulations of Web-based applications in a matter of hours.

We are firm believers in the power of prototypes – especially when they can present a compelling vision for an application. The idea that a business expert can create a good one seems a little far fetched.

They’re going to do what?

Business people can quickly lay out the page flow of simulations and create high fidelity pages that precisely mimic not only the look and feel of the final application, but the business logic and data interactions as well.

OK, page flow of a mockup, maybe – but business people will not precisely mimic the look and feel of the final application. Even if they could – it would be a bad idea. We’ve talked about the imperative of not specifying implementation details as part of the requirements process. Specifying implementation details is one of our top ten use case mistakes.

The idea of doing the data modeling and business process simulation is cool. Lombardi Software, another Austin company does this stuff – but for enterprise clients. Some of the best people I’ve worked with are at Lombardi, I respect their opinions, and know that they are big fans of being able to do process modeling – and have it drive applications in the real world. If iRise has a comparable interface for modeling, it could be a great tool for rapid prototyping.

Why would they do that?

The interactive simulations can become visual contracts between business and IT, serving as stable blueprints for what to build.”

OK – now I’m getting concerned. Why is it a good idea to have non-experts specify the branding, layout, interaction design, and usability of a web-based application? Assuming that an expert business process modeler is at the helm, we can expect that high-level workflow is well designed. But the user experience? Show me a business expert who’s competent at designing interfaces and I’ll show you a switch-hitter currently occupying the chair of a business expert.

But we need a good prototyping tool!

The screenshots showing how the application is used to build prototypes look very cool. This application looks like a good product, but their marketing copy sure is targeted at doing the wrong thing. Check out the bits about modeling of scenarios too.
What about the testimonials? Maybe we’re missing something.

Here are some excerpts from the testimonials (note: we’re starting to get excited about the product again)

    • …allow us to rapidly and iteratively validate the client’s needs early in the process ensuring we have the right requirements from the start
    • to visually validate requirements and “test market” applications prior to investing time and money in development
    • can engage their business stakeholders early in the process to visually identify missing system requirements, eliminate unnecessary functionality and discuss important process and policy issues

    Yes, yes, and yes!

    This is exactly how a prototype should be used.

    What should iRise do?

    1. Change the way they propose that their clients use iRise. Business analysts, while ideally suited to identify, prioritize and validate requirements, are in no way suited to the designing of software solutions. User experience experts are. A picture is worth a thousand words, and an interactive prototype is worth a thousand pictures. Why risk misleading or dissatisfying the stakeholders with a bad prototype? Why prevent your development team from being able to apply their skills to design a solution? If you’re outsourcing to a development group with limited capabilities, this mindset might seem rational. The answer is to bring design resources in house, not ask non-designers to design.
    2. Find small consulting companies with a lot of passion for product success and a big megaphone (hint hint), give them a free copy of the software, in exchange for an honest assessment of how well it works and suggestions on how to incorporate it into effective software development processes.

    Announcing Alkali Marketing – A little marketing for a big reaction

    Alkali Marketing main image

    Lauren Arbittier Davis recently started Alkali Marketing, a boutique marketing outsourcing company here in Austin.  I’ve personally worked with Lauren over much of the past decade, and couldn’t be more excited about her company!  When Tyner Blain is ready to build awareness (beyond our current viral approach), Alkali is who we’ll call.  In addition to a personal reccommendation of Lauren for anything you need, I also know some of her clients, have seen the work Lauren and Alkali have done for them, and know how pleased they are with it.

    Check out Alkali Marketing’s site, read their reviews, see what they can do, and schedule a meeting.
    Contact Alkali Marketing here.  Seriously.

    Scott