-2

Im studying about requirements but Im with some doubts. I read that it is common in a project to divide the requirements into user, functional and non functional and I studied about the three types.

I have two doubts below but they are related.

First is about the difference between the functional requirements and user requirements. The user requirements are the tasks that a type of user can perform with a system right? But that isnt also the functional requirement? For example in a site like ebay user requirements can be "Search catalog", "Pay Order", "Add item to shopping cart", Log-in", "logout", "recover password", "Get list of purchased products", right? But this arent also functional requirements? So why this distinction of user and functional requirements? Or functional requirements are not specified like this?

Also I read that the textual use cases are used to explore the user requirements and that then we can get the functional requirements from this analysis. So we should first identify the user requirements, like "Search catalog", "Pay Order", "Add item to shopping cart", Log-in", "Log-out", "Recover password" and these user requirements besides being user requirements are also use cases that we can create to get the functional requirements? But so, again the first doubt, which should be the functional requirements of these use cases/ user requirements above?

A use case for "Pay order" is for example:

Precondition: The user have one or more items in the shopping cart.

Trigger: Requester acceses the shopping cart.

Main Flow: The system displays detailed information about the shopping cart. The user confirms the order. The user select the payment method. The system informs the user about the result of the operation.

Postcondition: The order is confirmed and the information is stored.

How can we get functional requirements from this?

It is something like theese: "The user shall ble able to login", "The user shall be able to logout", "The user shall be able to pay an order", "the user shall be able to add an item to a shopping cart" It seems the same thing of just "Log-in, "Log-out", "Pay order".

  • 1
    It sounds like you're asking "What's the difference between user requirements and functional requirements?". Is that correct? – Dan Pichelman May 30 '17 at 21:17
1

First is about the difference between the functional requirements and user requirements. The user requirements are the tasks that a type of user can perform with a system right? But that isnt also the functional requirement? For example in a site like ebay user requirements can be "Search catalog", "Pay Order", "Add item to shopping cart", Log-in", "logout", "recover password", "Get list of purchased products", right? But this arent also functional requirements? So why this distinction of user and functional requirements? Or functional requirements are not specified like this?

In my experience, the source of a requirement (users, contractual obligations, legal obligations, business requirements) is orthogonal to the type of requirement (functional or non-functional). The translation of a requirement from a user's, domain's, the law's, or a business's terminology to one that meets the criteria of a good requirement is a process.

User requirements are statements, written in the user's natural language, about the functionality provided by or constraints under which the system operates. In this case, user requirements are transformed into one or more technical requirements that may be functional or non-functional.

In your example, the user may express a desire to pay for an order. The user may not think of it since they don't see it, but that would likely lead to a number of requirements that are both functional (how the user submits, stores, or updates payment information to the system) and non-functional (secure transmission and storage of payment information, privacy of personal information like credit card numbers or addresses, error handling about multiple duplicate requests, and so on).

Also I read that the textual use cases are used to explore the user requirements and that then we can get the functional requirements from this analysis. So we should first identify the user requirements, like "Search catalog", "Pay Order", "Add item to shopping cart", Log-in", "Log-out", "Recover password" and these user requirements besides being user requirements are also use cases that we can create to get the functional requirements? But so, again the first doubt, which should be the functional requirements of these use cases/ user requirements above?

I would consider your examples of "Search Catalog", "Pay Order", and others to be the use cases. I mentioned above that user requirements are often specified in the user's natural language (often the domain language). This is then transformed into a format that is a good requirement (among other things, complete, unambiguous, and verifiable). A use case is one method of capturing requirements in a way to make sure that they are good.

As you describe your use case preconditions, scenarios, and postconditions, you'll come across pieces that are functional and non-functional. For example, in a log-in use case, you may specify that the user enters their user name and password and then submits them through a secure form. The input data is functional, while the security is non-functional.

It is something like theese: "The user shall ble able to login", "The user shall be able to logout", "The user shall be able to pay an order", "the user shall be able to add an item to a shopping cart" It seems the same thing of just "Log-in, "Log-out", "Pay order".

Neither of those formats is good. Although "The user shall be able to login" and "log-in" may be equivalent, they aren't implementable requirements. They aren't complete, traceable, ambiguous, verifiable, and they don't specify importance.

  • Hm ok thanks for your answer now I understood better. But so the use cases should be create first and so we can understnad better the requirements and get the functional requirements from the use cases? But the use cases are also created to help in the implementation phase right? The requirements process have 4 main phases (elicitation, analysis, specification and validation), the use cases its in the analysis phase (to understand better and get the requirements) or in the specification phase (because the textual use cases specify with detail)? – JohnD May 31 '17 at 10:53
  • @JohnD Use cases are a method of capturing requirements (functional and non-functional) in a way that meets the needs of a developer. You would likely take user requirements, business requirements, contractual requirements, legal/regulatory requirements, and any other sources of requirements as input when creating use cases since they may have an impact on the flow. As far as the phases go, it's not so cut and dry. Writing down use cases is specification, but walking through them with users may lead to the elicitation of new requirements and the validation of the use cases. – Thomas Owens May 31 '17 at 12:31
0

First is about the difference between the functional requirements and user requirements. The user requirements are the tasks that a type of user can perform with a system right? But that isnt also the functional requirement?

User requirements are a subset of functional requirements. There is a lot of overlap. But there are functional requirements that are not user requirements, e.g. "History shall be automatically deleted after 30 days."

It is something like these: "The user shall ble able to login", "The user shall be able to logout", "The user shall be able to pay an order", "the user shall be able to add an item to a shopping cart" It seems the same thing of just "Log-in, "Log-out", "Pay order".

Requirements must be rigorously defined with zero ambiguity. If you are confident that "pay an order" and "logout" are unambiguously defined terms, fine. I don't think they are though.

Instead of "a user must be able to login," a well written requirement set may contain the following:

  • An end user with a user name and password must be able to establish a session, with the following exceptions: (a) the user is blacklisted (see section XX.YY), (b) the user is locked out (see section AA.BB), (c) the user is attempting to access the system from an IP address in a blacklisted geolocation region (see section DD.EE.FF)
  • A blacklisted user who attempts to authenticate shall be presented with Message 104.
  • A user in locked out status who attempts to authenticate shall be presented with message 105.
  • A user who attempts to authenticate from a blacklisted IP address shall be presented with message 106.
  • An end user without knowledge of a user name and password must not be able to establish a session.
  • An end user who has established a session must be able to navigate to any of the pages listed in Table 1.
  • All users should be able to navigate to any of the pages listed in Table 2, regardless of whether they have established a session.
  • If a user attempts to navigate to a disallowed page, the system shall present an HTTP 403 status. Note: Specific UX may be browser-specific.
  • If a browser is left unattended, a session must end between 29 and 31 minutes after the last page submission.
  • After a session has ended, the system must behave exactly as if the system had never been established.
  • If the user closes the browser, the system must behave exactly as if the session has ended.

Each of the above map naturally to use cases and test cases, since the preconditions and rules are clear enough, and each logic path is spelled out separately. But that doesn't mean there is a 1:1 mapping. You could have many use cases associated with a requirement, and nearly every use case must obey several requirements at the same time; use cases and requirements are tied together with a traceability matrix.

Use cases tend to be very detailed and do not have simple names like "authenticate" or "login." In my experience they are identified by a code of some kind, e.g. "Auth-BF-01" would be authentication basic flow #1. There may be basic flows 2 and 3 as well. Basic flows are also called "happy path." Meanwhile, exception or error flows might be named "Auth-AF-01" where "AF" stands for "alternative flow." Alternative flows are used for things like password invalid or system failure.

  • Thanks for your answer. But so in your opinion make sense to define user requirements and functional requirements? Or just functional requirements is good enough? And you say that each of the above map to use cases and test cases, for example, if a user with a session must be able to access the pages in table 1. The use case for this is "Access pages"? And the test case I didnt understand well, its like a requirement its just well defined if is testable, for example we can test if the user can acess the pages in the table 1, so the requirement is well defined? – JohnD May 30 '17 at 23:39
  • Use cases are very different. I added a few notes at the end of my answer. – John Wu May 30 '17 at 23:44
0

The way you find out if it's a real requirement or not is by following Robert's Golden Rule for Software Requirements:

Every genuine requirement is accompanied by an Acceptance Test that proves the requirement has been met. Does running this test clearly and ambiguously verify that the requirement has been fulfilled? If you don't have such a test, it's not a requirement; it's a "feature" or "wish."

Requirements gathering is the subject of complete books. You can get a better idea of how to gather legitimate, useful requirements by reading one of those books. See here.

  • Thanks for your answer. But do you have an example of a correct requirement that is accompanied by an acceptance test to check how to do it correctly? Beucase I think that Pay an order and etc its a requirement, can be not well described but Its a user requirement right? – JohnD May 30 '17 at 23:32
  • Thank you. It seems that this is more for agile, do you know if it is ok in more sequential methodologies its ok to use user stories and not user cases with acceptance tests? Or user stories is just for agile? – JohnD May 31 '17 at 10:46
  • Not specific to agile. – Robert Harvey May 31 '17 at 13:53
  • @JohnD - "The system shall provide a means for the customer to pay for an order." is a perfectly valid requirement that can be easily tested. However, that requirement then raises other questions that will add additional requirements. e.g. The system shall allow the customer to pay using cash, credit card or Apple Pay. (Generally I'd make them 3 requirements but for this example...). Each of those payment types raises other questions that generate more requirements. Keep iterating until the intent is clearly stated in the requirements. – Dunk May 31 '17 at 23:48

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.