Must a Requirement be Feasible?

Within a discussion on the Seilevel message board about the characteristics of a good requirement, Elaine and Gescober discussed whether a requirement must be feasible in order to be a good requirement.

While initially it looked like they had opposite opinions--Elaine: No, Gescober: Yes-- they’ve seem to have come to some meaningful points of agreement:

• A requirement must be feasible to build a project.


• Explicit discussion and resolution of requirements which are not feasible allows you to keep expectations in synch with reality. If a requirement is not feasible, you must decide whether to alter the vision and expectations of the project to exclude it, or halt the project because it cannot sufficiently meet expectations.

It may seem like an obvious conclusion, yet how many times have you seen it happen:

• Requirements left out because they are infeasible, resulting in disappointed users --“Why didn't you tell me I couldn't have what I wanted?”


• Requirements sent to development which are infeasible, putting the development team in a no-win situation--“Why did you commit me to building what I know can’t be built with the constraints I have?”

We must be candid with our users; if they want something they can’t have (for what they are willing to pay), we must tell them.

No field length guidelines

I found myself last year working on a UI heavy project, in which we were specifying detailed requirements associated with individual UI elements.  One of the elements that the customer wanted to define were the field lengths for when users enter text.  This text might include street address, city name, zip codes, etc.

Seems simple.

I'll just go look up the standard lengths for such things.

Except there aren't any.

I sent Emails out to friends of mine who specialize in information management, and got a common theme back.  No standards.  All pointed me to a book by Luke Wroblewski called Web Form Design.  Unfortunately, this simply contained some general guidelines.

We chatted a bit about why these standards don't exist, and came up with several possibilities:

1.  Database design is being done first, and once field lengths are set in the database, that becomes a technical constraint on the UI.

2.  Arbitrarily large limits are set in order to make sure that fields of "any" length can be handled (allocating 255 characters for last name is PROBABLY sufficient, right?).

3.  Good standards aren't really possibly, due to localization issues.

The reality is that all three have led us to where we are today.

Anybody want to write a standard?

Strength Finder 2.0

Our company is currently doing an evaluation of our consultants and support staff using Strength Finder 2.0. I was skeptical at the beginning of this process, but I've been impressed by the results so far. We have a lot of different types of consultants within Seilevel, but we're seeing a couple different themes:

Strategic: These seem to be the people who are best at kicking off projects. These are the consultants who work best in problems of ambiguity.

Achiever: These people are driven to accomplish things every day.

Responsibility: These are the people who are generally detail oriented who feel obligation to finish tasks.


Not all of our consultants are strong on each of these, but we do find that in order for projects to be successful, we need to have all three elements present within the project team.

http://search.barnesandnoble.com/Strengths-Finder-20/Tom-Rath/e/9781595620156/?itm=1

What Should Your Application's Response Time Be?

Interaction Elasticity by Jakob Nielsen contains some useful data for those of us writing usability requirements:

Yes, we know that response times must be less than 1 second for navigation to feel seamless and less than 10 seconds to prevent a user's attention from wandering. These time limits are caused by the human brain's structure and are thus firm and stable decade by decade (indeed, century by century).

The entire article is interesting--give it a quick read for some nice reference material on determining response time requirements.

Recognizing Patterns and doing something about it.

After I've solved the same problem half a dozen times, even I start to notice patterns. Pattern recognition is an important skill for people doing requirements. However, if you don't have a way of acting on the pattern recognition, you aren't helping yourself.

I've begun to catalog the patterns that I see associated with software requirements. Formally capturing and articulating of the models associated with a particular pattern is probably beyond the scope of a simple blog post, but the base technique I use with patterns is simple enough to describe here.

I start with a spreadsheet of questions that I seem to have to ask associated with the pattern. For example, if I'm working on an application that has a login, then I'll have to answer the same questions that I had to answer the last time I worked on an application with a login:

1. What credentials are required to log in?

2. Is the login process dependent on whether cookies are enabled?

3. Is the login process dependent on what machine I'm using?

4. Are there any security measures in addition to the user provided login credentials?

5. Are we tracking the number of attempted logins?

6. Are there thresholds of attempted logins that should trigger us to do other things?

7. What if I forget my password?

8 What if I forget my username?

I put these questions in the first column. I then have a blank column next to it for the answer. The third column contains the impact of the answers. The impact might be a list of use cases that are impacted, or other models that I might have to change based on the answer.

As I use this pattern more and more often, the underlying models become more and more reusable as I flesh them out. Ultimately, I begin to build a personal pattern library.