Feature v.s. requirement

[m.slingerland]

Hello,

I would like to know the difference between a feature and a requirement (Requirement Model). Can anyone tell me when to use a feature or a requirement?

Thanks!

[Paolo F Cantoni]

Hello,

I would like to know the difference between a feature and a requirement (Requirement Model). Can anyone tell me when to use a feature or a requirement?

Thanks!

In normal usage, a requirement is what the systems has to to (is required to do), a feature is what the system actually does (it is a feature of the system).

Part of the audit process is that the system actually does what it is required to do.  You should be able to trace requirements to system objects and then trace the system objects to features; thereby the features can be mapped to the requirements.

Does that help?
Paolo

[m.slingerland]

Well I don't think that I understand it (I'am new to UML/EA

I have two Use Cases:

- Create proposition/offer
- Create order
- Select customer

Use case "Create proposition/offer" and use case "Create order" are both using "Select customer".  

Select customer means:
The user has to be able to select a customer from the database. The user has to be able to search for a customer (e.g. on name, adress, phone number) and select a customer.

Could you give me an example of how to model this?

Thanks!

Matthijs

[Paolo F Cantoni]

Start by listing (on this topic/thread) any requirements that caused you to create these three use cases.

If you can't, then what are they doing here?

Paolo

[m.slingerland]

Create new proposition:
- User has to be able to create a new proposition;
- User has to be able to fill in a customer-code;
- User has to be able to search for the customer code (in a customer database);
- User has to be able to choose a customer contact;
- User has to be able to add products to the new proposition;
- User has to be able to fill in a date/action to call the customer (ask the custmer if the proposition is ok or not)
- User has to be able to change the proposition into an order;
- User has to be able to cancel the proposition;

Create new order:
- User is able to create a new order;
- User has to be able to fill in a customer-code;
- User has to be able to search for the customer code (in a customer database);
- User has to be able to add products to the order;
- User has to be able to fill in the delivery date;
- User has to be able to fill in the delivery adress;
- etc.

Matthijs

[Paolo F Cantoni]

Are you building a bespoke product for a single customer or are you creating a generic product for general sale?

If the former, what you've listed doesn't sound like customer generated requirements (and hence may be the source of your confusion).

If the latter, it is often tough to cast Marketing's features as requirements (and hence may be the source of your confusion)

HTH,
Paolo

[m.slingerland]

I'am building a system for a single customer. What type of user requirements do you expect in this kind of situation? Are my user requirements not detailed enough?

Matthijs

[Paolo F Cantoni]

I'am building a system for a single customer. What type of user requirements do you expect in this kind of situation? Are my user requirements not detailed enough?

Matthijs

No, the reverse - they are (perhaps) too detailed for normal customer requrements.

I would recommend you move up the requirements you have at least one level of abstraction.  You need to have the requirements and features at the same level of abstraction.

System must allow user to open an arbitrary file - requirement

System provides universal file dialog to allow the user to open an arbitrary file - feature

Is this now a bit clearer?
Paolo

BTW: any one else can add their cents worth...  

[sargasso]

   Nothing (much) to add here, Paolo, that's a good High D!

One thing that is confusing to both UML neophytes and experts alike (or at least to me it is  :-/ ) is the duality that you have raised.

Many many moons ago I read a little paperback book about using object modelling approaches at the business process level.  It was fine read... wish I had the ref.  But one mind-thing the author was adamant about was considering the entire system to be like a set of rooms separated by pigeon holes.  When someone in one room needed something (a "service") that was provided by someone in another room, they stuck a request in a pigeon hole.  Some person on the other side of the hole took the request and validated it and if appropriate "did it".  Not exactly an original or deep view of object modelling ... but wait.  His point was to consider yourself (the modeller) in one room only.  

That is, (ahem), Requirements reflect only the view of the requesting actor.  Similarly, responsibilities reflect only the view of the service provider.  So. Then. What is a use case?  IMO(YA) only the view of the user.  

It should clearly and succinctly express what "I" want the system to do, in order to achieve that age old "user goal".    "I" dont want it to "provide a M$ListBox of all customers in the system", "I require" it to "provide a means to easily enter and store the details of a new Proposition, including optionally a means to relate the proposition to known customers.

Matthys,  I'll leave this now, with one last set of double quotes...

So when "I" stick the request to create a new Proposition through the pigeon hole, what should I expect "the system" to "provide"?  (One last clue, dont design the system inside a use case, it leaves it messy and smelly like last night's pizza box.)

hth
bruce

[mikewhit]

My reading was that Features were applicable in what is termed "product-line" modelling in which you may have variants with different feature sets - an example might be a bar games machine where the manufacturer has a base architecture but then different machines might have a note reader as well as a coin reader, a credit card port, a ticket dispenser, a link to a back-office system.

Those 'variable requirements' are Features.

Also see first para here: http://www.ou.nl/Docs/Faculteiten/INF/Publicaties/2006/C3_062_Roubtsova.pdf

[sargasso]

  Found it! "Business Engineering with Object Technology" by David A Taylor(c)1995 by Enterprise Engines Inc. published by John Wiley and Sons ISBN 0-471-04521-7

b

[sl@sh]

To complement your example:

If someone wants you to build a (vending) machine that is 'able to accept payment from 99% of all possible customers', this would be a requirement.

If you then model a machine that can accept both coins and credit cards, these are the machine's features.

Your task as a system architect then would be to make sure that the actual features (accepts coins and credit cards) of your machine model are sufficient to satisfy the requirement given (able to accept payment from 99% customers).

Note that the features can be different for different models, and depending on specific circumstances you might need different features to fulfill the requirements (i. e. on an international airport you might need to accept various different currencies).

Also note that the requirement I gave doesn't prescribe any details of the features you might need to implement. It is just a description of what the machine needs to be able to perform.

HTH

P.S.: IME the main problem of the requirements analysis is, that the customer (the one who wants you to build the system) often tells you what features the system should have, not what he requires the system to be able to. Try talking your customer out of this habit, or at least work with him to be able to back-translate his list of features into actual requirements.

[Paolo F Cantoni]

[size=13][SNIP][/size]
PS you to build the system) often tells you what features the system should have, not what he requires the system to be able to. Try talking your customer out of this habit, or at least work with him to be able to back-translate his list of features into actual requirements.

I can relate to this...  A long, long, time ago, (for my sins) I was the IS manager for the Software Services Arm of Digital Equipment Corporation (DEC) Australia - in it's hey day... [aside]bruce, are the (twin) towers still above Chatswood railway station?[/aside]

Anyhow, I used to walk into management meetings and the questions would be "why haven't you implemented this in DEC RBMS" not "this the problem we need a solution to"...  I called it "solutions in search of a problem".  Too many users know what they want, but not what it needs to do...  And when you build what they wanted, but it doesn't do what needs to be done - it's your name on the box...

As you say, they need to be trained out of the habit.

Paolo

[sl@sh]

When I worked in a software company one of our regular customers framed this sentence after one of our "requirements meetings": "As always, you know how it is: please implement the system we need, not the one we want!"  

[sargasso]

sl@sh, (of no aparent nomenclature,) said:

he/she said "As always, you know how it is: please implement the system we need, not the one we want!"  Grin

Ah! grasshopper, almost you have the golden toasted flake of corn in your grasp and yet you seek to wonder about how cows understand daylight saving time.

Clue: Deliver what the b@st@rds "want", not what they "need". The science is in manipulating that which they "say" they want, into what they "mean" they want.  

----------
FWIW
bruce

amended..
Blooddy hell! thet was ret too obscure for even me, leddie.  I just meant that "we" have no right in determining what the user really "needs" just that they have goal to achieve. Its our job to (somehow)understand that goal and make it easier for them to achieve it.

sorry