home

Use case and Functional requirements

warning: realpath() [function.realpath]: Unable to access /var/www/vhosts/requirementsnetwork.com/httpdocs/sites/requirementsnetwork.com/files/webform/ in /var/www/vhosts/requirementsnetwork.com/httpdocs/includes/file.inc on line 190.

How do you deal with the relationship between use case and functional requirements? do you repeat the system funciton in functional requiremetns section with more details or just leave the system functions in the use case description?

for example, in use case it says:
user selects account type
system presents a list of transactions

appreciate it if you could shed some light

Regards,
Simon

Use Cases, Functional Requirements, and Interaction Design

Roger, I have to disagree with you on two seperate issues:

1. Use cases are not (necessarily) interaction design.
2. Interaction design is a functional requirement.

First of all, an "essential" use case doesn't include any "interaction design" other than necessary to actually describe the requirement. To use your example, an essential use case for purchasing an item would look like:

1. Customer selects items to purchase.
2. System calculates total cost of purchase.
3. Customer provides payment.
4. System records payment.
5. System issues reciept.

Note that this use case says nothing about interaction design other than what is, in fact, absolutely necessary to buy something. I could probably flesh it out in more detail and still not say anything about the UI or what is being interacted with, and I'd still contend that this use case has value.

I'd also contend that most of the steps performed by the system in the essential use case are in fact functional requirements.

2. I think it's fair to say that interaction design may well be a functional requirement. Functional requirements are generally defined as the behaviour that a system needs to have in order to meet a customer need. There are a lot of cases I can think of where the UI can fall into that category.

I know you personally feel that requirements should be as broadly defined as it's possible for them to be, but I don't think that's appropriate for all circumstances. You're coming at this from the perspective of a product manager, with the goal of coming up with a solution that will stand out in the marketplace. From that perspective, it's reasonable to take the requirement as far back as you possibly can in order to ensure that you consider the widest range of possible solutions.

However, my experience is somewhat different--I've always been a BA working in a corporate environment, trying to juggle multiple stakeholders with competing needs and deal with development teams who typically don't have a deep understanding of the business. In general, I'm also enhancing existing capabilities rather than trying to create something new from scratch.

Because of this, I have a need to ensure that all stakeholders are in agreement, that there is a shared understanding of what is to be built, and that we know what impact the proposed solution will have on the daily work of users. From my perspective, anything visible to the users is a requirement.

---------------------------------------
Kevin Brennan, PMP
Sr. Consultant, blue sands Inc.
Vice-President, Body of Knowledge, IIBA

    Sponsored Announcements & Special Offers

view counter

Whitepaper from HP - Why Focus on Requirements Definition Management in the Application Lifecycle?

Increasingly, smart businesses are looking much closer at requirements definition (RD) and requirements management (RM) (sometimes grouped together under the Gartner-coined phrase, requirements definition management (RDM)) to streamline the entire application lifecycle. Why? Because systematic and effective RDM captures software defects earlier in the lifecycle, and it reduces the overall likelihood that defects will be introduced. That’s important. How important? According to one study, the cost to fix a defect after delivery is more than 100 times the cost to fix it in the requirement and design phase. No business wants to be hit with that bill. Now to add to this the growing interest in agile development techniques as a way to deliver higher quality applications and we have an interesting recipe for success.

Download a Free Copy

view counter
© 2007-2010 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group