Posts tagged Requirements

Agile Modeling

Oct 25th

Posted by John Peltier in Requirements

3 comments

One of the challenges I encounter with producing customer requirements for consumption by a development team is overcoming the barrier of understanding. My company does not have dedicated business analysts, so the role of translating customer needs to development needs and architecture is typically handled by our developers. What if they don’t see the big picture of what the user wants, but instead only see a large collection of unrelated detail?

Organizing requirments in categories can help to provide a mental framework, but navigation becomes difficult past 2-3 levels. It’s becoming apparent to me that in order to bridge the gap, some diagramming and coalescing of requirements into pictoral form must be provided. The question is, of the tens of possible types of models, which types are most effective and therefore worth the time?

I’ve found a site that details numerous types of models and diagrams, and provides handwritten examples of each. The silver-bullet takeway from this site is the following:

“know a wide variety of modeling techniques … apply the right artifact(s) for the situation at hand.”

My current problem is that I’ve been away from my brief studies in UML during my Master’s program for six years, and I don’t have command of that wide variety of modeling techniques. I have, therefore, just shared with you the newest item on my personal to-do list…

, , ,

User Stories

Oct 25th

Posted by John Peltier in Requirements

No comments

My team is doing an experiment with user stories; I’m currently gathering requirements for a global licensing module to support multiple applications and regions in my company, and for that project, all goals and customer requirements are being written in the user story format.

User stories are loosely defined as a concise explanation of a need, the person with the need, and the objective that can be achieved by meeting the need. This provides context that a simple “The system shall…” statement cannot. On the other hand, because of the “As a ____, I need ____ so _____” format, user stories are conducive to wordiness. One suggestion to mitigate this risk is to write them initially on index cards–presumably if you’ve filled up the card, you know you’ve written enough or too much.

As for what to write on the card, following the format makes it relatively clear–however, analysis still needs to be applied so that the “I need _____” is completed with the “what,” rather than the “how.” I find it difficult sometimes to step out of the “how,” and sometimes find more “how” than I like to admit when I read old requirements, but the less of it, the better!

An idea that’s new to me is the acceptance story; this is a template that allows the analyst to designate how a requirement shall be deemed satisfied, with the following syntax:

Scenario 1: Title
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…

This may be cumbersome to write for each requirement/story in a requirements document; my first thought, without having tried to implement these, is to write them for selected user stories only–presumably, those that could benefit from additional clarification. Any thoughts?

, ,

Non-functional Requirements Checklist

Oct 25th

Posted by John Peltier in Requirements

1 comment

When developing a new software application or working to architect a new platform, the realm of non-functional requirements poses a challenge to creativity. What *should* the system requirements be?

If your new application is to be built to integrate with older software, you must keep an eye towards the languages and frameworks used–because your new application may demand resources totally foreign to the older software you integrate with, which might demand a significant investment on the part of the users of your older application to move up to the new one.

Beyond that, what kind of performance metrics should be considered “ideal”? For an application that steps into new territory for your organization, is a response time for a particular operation of a particualr number of seconds (i.e. measurable) defensible, or even feasible? Is the proper definition of a response time more useful if it is generic, without reference to a particular number of seconds? Perhaps crafting measurable numbers that are derived from the measurements of competing software or similar applications is the answer.

More food for thought about areas to consider within the category of non-functional requirements can be consumed here.

EDIT: If you’re really in the mood for a load of categories to consider, here’s Wikipedia’s list of 70-odd Ilities for you to consider!

, ,
«123