1

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?

Improve this question
1
  • 1
    Comment about the practicality of putting "Question on" in the title instead of an actual description of the question. Hint: trying to formulate a good, succinct title will help you get to grips with your question.
    – Joachim Sauer
    Feb 13, 2013 at 17:39

3 Answers 3

Reset to default
3

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: ..."

Improve this answer
4
  • Thanks Kevin. As asked above , is it ok to specify technical service names as part of requirement. In an ideal scenrio the requirement would be defined and only after design discussions it would be decided that different services might have to called for setting up user info in different states. So should we really have a table for different states and associated services?
    – Punter Vicky
    Feb 14, 2013 at 3:38
  • @PunterVicky: if the services already exist, then it makes perfect sense. If they are to be built, then IMO it's a design decision. Requirements describe the needs of users, not the implementation.
    – kevin cline
    Feb 14, 2013 at 10:25
  • @kevn , thanks again. users required is that the user info provided must be stored. If I state how the contact information needs to be stored as part of the requirements , doesn't it mean mixing design with implementation? In this case , yes we already know that the services exist.
    – Punter Vicky
    Feb 14, 2013 at 13:08
  • @PunterVicky: it depends. For example, suppose there is an existing database, and the data for the new application must reside there so it can be accessed by an existing system. That's a requirement from the users of the existing system. On the other hand, if you are creating a brand new system, then there could be requirements for data persistence, security, etc. but the use of a SQL database would be a design decision.
    – kevin cline
    Feb 14, 2013 at 18:33
2

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.

Improve this answer
3
  • 1
    I think as a requirement, that is way, way too vague. If I read just that statement, I would ask - what 'user information'? Where does it come from? Is where it comes from a strict requirement? What does 'register' mean in this sense? I'd consider splitting this into at least 2 or 3 requirements, and if necessary adding an appendix with the states, services, and required data fields that can be 'registered' (queried? scraped? Is it an API?) for each. Note that none of this defines the 'how' of 'registration'.
    – John Lyon
    Feb 13, 2013 at 23:46
  • Thanks Jozzas. Is it fine to specify the actual technical service names as part of requirement?
    – Punter Vicky
    Feb 14, 2013 at 3:34
  • 1
    @jozzas - as th OP didn't specifiy I don not see how GlenH7 could! In practice you would specify Postal Address, Email Address, date of birth or whatever was required later on. Usually I would add this as a list in an appendix and keep the requirement as simply "contact details" -- people find it easier to suggests amendments to a separate list where they would be reluctant to change the wording of an "agreed" requirement.
    – James Anderson
    Feb 14, 2013 at 7:49
1

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.

Improve this answer
1
  • Thanks James. With respect to data , I could say for NY - this data needs to be stored , for NJ - this data needs to be stored etc [as part of table]. But if I specify how it needs to be called [by calling which interface], doesn't it amount to mixing design with requirements?
    – Punter Vicky
    Feb 14, 2013 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.