I have a scenario where a specific webservice must be consumed based on the state to setup user info. For instance if the state is NY or NJ call service A , if state is WA call service B etc. But specifying what service must be called is I guess is “HOW” to setup a user info and not a “WHAT”.
So should I just have single requirement stating system must have the capbality to setup up user info based on state?
EDIT: I would also like to add that the services implemented for different states might want different info to be provided in addition to basic details such as first name and last name. Should the services , input to the services , output from the service , what the program needs to do with the output etc be part of system requirements? I guess all these deal with “HOW” more than “WHAT” – hence is it in the requirements realm?
1
As described, it sounds like a design decision, not a system requirement. I think the requirement should sound like this: “The marklar depends on the user’s state of residence. For users in NY, NJ … . For users in WA, … etc.” or “The marklar depends on the user’s state of residence, and is calculated according to the following table: …”
4
Correct, you’ll want to start with a single requirement like:
System must have the capability to register user information based upon geographical state
As that phrasing avoids the particulars about how the information is supposed to be registered.
It also allows the generation of a main service InitialRegistration() that pulls common information for all the cases along with the geographic state. From there, InitialRegistration() can call StateSpecificRegistration() without the client application or end user having to worry about what to do.
3
You should be able to word this as a single requirement as described by the other posters.
The problem with defining this as two or more requirements is this pushes your developers towards designing the “NY/NJ” interface and the “WA” interface. When a generic interface with options/rules driven by location would probably be a superior implementation.
1