Search code examples
classificationrequirements

Correct classification of client requirements for UML diagrams?

I needed to classify the following RQs as a

  • Design objective,
  • Design Decisions,
  • Functional Req,
  • Non-Functional Req

(so I can do class diagram and use case diagram based on them later).

I wanted to know if I'm on the right track here (the bold face is my guess for each requirement):

Requirement document Purchase Commitment System.

  1. The software is to calculate a number of details needed to purchase by a factory in order to produce its products. (Design decision)

  2. The software must be written in C++ or Java Programming Languages on the computer IBM PC. (Design decision)

  3. The number of products should be equal to 4. (Non-Functional Req)

  4. A general aim in the design of the software is to improve the portability of software. (Non-Functional Req)

  5. The system should accept as input (make as a text file) the data about a number, amount and price of detail for every type of products. (Functional Req)

  6. A number of details for every type of products should not be less than 5.

  7. The first and second type of products should have 2 same details. The second and fourth type of products should have one same detail. The third type of products should have 2 same details with the fourth type and one same detail with the first type of products. (Design Objective)

  8. The operator should be logged in and logged out to the system by login and password. (Design Objective)

  9. At the beginning an operator must provide the following items of data (a validation of input data should be provided):

    • A number of every type of products to be produced by the factory for 3 months ahead. (Functional Req)

  10. The software must produce for each action of an operator a report (the report should be saved in a file by the operator's request). The report must consist of : (Functional or Design Objective Req) -A number of every detail needed to purchase.

    • The total price for every detail.
    • The total price for all the details
Solution

  • A functional requirement tells what the software shall do. A non functional requirement tells something about how the software shall be or how well it should do what it does.

    Software design is about the structure and the behavior of the software. If some statement seems arbitrary and you think the software could fulfil all the requirements but differently, then there are chances that it's more about design than requirements. A design objective tells what the design must ensure (ambiguous: at the stage of the requirements, it's difficult to make the difference between non functional requirements and design objective). A design decision is a decision on the behavior or the structure of the software.

    With this in mind, here an analysis:

    1. What the software shall do ==> Functional requirement (FR)
      If we'd change this, the software would no longer do what is expected, so it can't be a design decision.
    2. How the software shall be ==> Non functional requirement (NFR)
      Not really about structure or behavior of the software. The language will not impact use case nor class model, so it's not really a design decision IMHO.
    3. Arbitrary decision about cardinality in object model ==> Design decision (DD)
    4. "aim in the design" ==> Design objective (DO)
    5. What the software shall do ==> FR
    6. Arbitrary constraint about object model ==> DD
      If it would be no less than 3 or no less than 10, the software would still fulfil the functional requirements. However this depends on the context. If it would turn out that the software would not be fit for purpose if these limits would not be respected, then it could be FR.
    7. Arbitrary constraint on object model ==> DD
      The purpose of this statement is unclear. It looks like some arbitrary constraints that could allow to generalize some categories.
    8. What the software shall do ==> FR
    9. Arbitrary decision on the interaction ==> DD
      I think that the data could be entered at another moment, or in a different way (3 times 1 month). Therefore I think it is DD. However, one could argue that the system shall offer a 3 month planning. So FR cannot be excluded, although I would expect it to be expressed differently.
    10. What the software shall do ==> FR