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

JohnD
  • 3

3 Answers3

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.

Thomas Owens
  • 85,641
  • 18
  • 207
  • 307
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.

Robert Harvey
  • 200,592
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.

John Wu
  • 26,955