Specifying Requirements

Prose

What

🏆 Can explain prose

A normal textual description (i.e. prose) can be used to describe requirements. Prose is especially useful when describing abstract ideas such as the vision of a product.

📦 The product vision of the TEAMMATES Project given below is described using prose.

Vision

TEAMMATES aims to become the biggest student project in the world (biggest here refers to 'many contributors, many users, large code base, evolving over a long period'). Furthermore, it aims to serve as a training tool for Software Engineering students who want to learn SE skills in the context of a non-trivial real software product.

Avoid using lengthy prose to describe requirements; they can be hard to follow.

Feature List

What

🏆 Can explain feature list

Feature List: A list of features of a product grouped according to some criteria such as aspect, priority, order of delivery, etc.

📦 A sample feature list from a simple Minesweeper game (only a brief description has been provided to save space):

Basic play – Single player play.
Difficulty levels
- Medium-levels
- Advanced levels
Versus play – Two players can play against each other.
Timer – Additional fixed time restriction on the player.
...

User Stories

Introduction

🏆 Can write simple user stories

User story: User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. _{[Mike Cohn]}

A common format for writing user stories is:

User story format: As a {user type/role} I can {function} so that {benefit}

📦 Examples (from a Learning Management System):

As a student, I can download files uploaded by lecturers, so that I can get my own copy of the files
As a lecturer, I can create discussion forums, so that students can discuss things online
As a tutor, I can print attendance sheets, so that I can take attendance during the class

We can write user stories on index cards or sticky notes, and arrange on walls or tables, to facilitate planning and discussion. Alternatively, we can use a software such as GitHub Project Boards to manage user stories digitally.

^{[credit: https://www.flickr.com/photos/jakuza/2682466984/]}

^{[credit: https://www.flickr.com/photos/jakuza/with/2726048607/]}

^{[credit: https://commons.wikimedia.org/wiki/File:User_Story_Map_in_Action.png]}

a. They are based on stories users tell about similar systems
b. They are written from the user/customer perspective
c. They are always written in some physical medium such as index cards or sticky notes

a. Reason: Despite the name, user stories are not related to 'stories' about the software.
b.
c. Reason: It is possible to use software to record user stories. When the team members are not co-located this may be the only option.

Critique the following user story taken from a software project to build an e-commerce website.

As a developer, I want to use Python to implement the software, so that we can resue existing Python modules.

Refer to the definition of a user story.

This user story is not written from the perspective of the user/customer.

Bill wants you to build a Human Resource Management (HRM) system. He mentions that the system will help employees to view their own leave balance. What are the user stories you can extract from that statement?

Remember to follow the correct format when writing user stories.

User story format: As a {user type/role} I can {function} so that {benefit}

As an employee, I can view my leave balance, so that I can know how many leave days I have left.

Note: the {benefit} part may vary as it is not specifically mentioned in the question.

Details

🏆 Can write more detailed user stories

The {benefit} can be omitted if it is obvious.

As a user, I can login to the system ~~so that I can access my data~~

It is recommended to confirm there is a concrete benefit even if you omit it from the user story. If not, we could end up adding features that have no real benefit.

We can add more characteristics to the {user role} to provide more context to the user story.

As a forgetful user, I can view a password hint, so that I can recall my password.
As an expert user, I can tweak the underlying formatting tags of the document, so that I can format the document exactly as I need.

We can write user stories at various levels. High-level user stories, called epics (or themes) cover bigger functionality. We can then break down these epics to multiple user stories of normal size.

[Epic] As a lecturer, I can monitor student participation levels

As a lecturer, I can view the forum post count of each student so that I can identify the activity level of students in the forum
As a lecturer, I can view webcast view records of each student so that I can identify the students who did not view webcasts
As a lecturer, I can view file download statistics of each student so that I can identify the students who do not download lecture materials

We can add conditions of satisfaction to a user story to specify things that need to be true for the user story implementation to be accepted as ‘done’.

As a lecturer, I can view the forum post count of each student so that I can identify the activity level of students in the forum.

Conditions:

Separate post count for each forum should be shown
Total post count of a student should be shown
The list should be sortable by student name and post count

Other useful info that can be added to a user story includes (but not limited to)

Priority: how important the user story is
Size: the estimated effort to implement the user story
Urgency: how soon the feature is needed

User stories for a travel website (credit: Mike Cohen)

As a registered user, I am required to log in so that I can access the system
As a forgetful user, I can request a password reminder so that I can log in if I forget mine
[Epic] As a user, I can cancel a reservation
- As a premium site member, I can cancel a reservation up to the last minute
- As a non-premium member, I can cancel up to 24 hours in advance
- As a member, I am emailed a conﬁrmation of any cancelled reservation
[Epic] As a frequent ﬂyer, I want to book a trip
- As a frequent ﬂyer, I want to book a trip using miles
- As a frequent ﬂyer, I want to rebook a trip I take often
- As a frequent ﬂyer, I want to request an upgrade
- As a frequent ﬂyer, I want to see if my upgrade cleared

Choose the correct statements

a. User stories are short and written in a formal notation.
b. User stories is another name for use cases.
c. User stories describes past experiences users had with similar systems. These are helpful in developing the new system.
d. User stories are not detailed enough to tell us exact details of the product.

Explanation: User stories are short and written in natural language, NOT in a formal language. They are used for estimation and scheduling purposes but do not contain enough details to form a complete system specification.

Usage

🏆 Can use user stories to manage requirements of project

User stories capture user requirements in a way that is convenient for scoping, estimation and scheduling.

[User stories] strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written. _{[Mike Cohn, MountainGoat Software 🔗]}

User stories differ from traditional requirements specifications mainly in the level of detail. User stories should only provide enough details to make a reasonably low risk estimate of how long the user story will take to implement. When the time comes to implement the user story, the developers will meet with the customer face-to-face to work out a more detailed description of the requirements. [more...]

User stories can capture non-functional requirements too because even NFRs must benefit some stakeholder.

📦 An example of a NFR captured as a user story:

As a	I want to	so that
impatient user	to be able experience reasonable response time from the website while up to 1000 concurrent users are using it	I can use the app even when the traffic is at the maximum expected level

Given their lightweight nature, user stories are quite handy for recording requirements during early requirements gathering.

💡 Here are some tips for using user stories for early stages of requirement gathering:

Define the target user:
Decide your target user's profile (e.g. a student, office worker, programmer, sales person) and work patterns (e.g. Does he work in groups or alone? Does he share his computer with others?). A clear understanding of the target user will help when deciding the importance of a user story. You can even give this user a name. e.g. Target user Jean is a university student studying in a non-IT field. She interacts with a lot of people due to her involvement in university clubs/societies. ...
Define the problem scope: Decide that exact problem you are going to solve for the target user. e.g. Help Jean keep track of all her school contacts
Don't be too hasty to discard 'unusual' user stories:
Those might make your product unique and stand out from the rest, at least for the target users.
Don't go into too much details:
For example, consider this user story: As a user, I want to see a list of tasks that needs my attention most at the present time, so that I pay attention to them first.
When discussing this user story, don't worry about what tasks should be considered needs my attention most at the present time. Those details can be worked out later.
Don't be biased by preconceived product ideas:
When you are at the stage of identifying user needs, clear your mind of ideas you have about what your end product will look like.
Don't discuss implementation details or whether you are actually going to implement it:
When gathering requirements, your decision is whether the user's need is important enough for you to want to fulfil it. Implementation details can be discussed later. If a user story turns out to be too difficult to implement later, you can always omit it from the implementation plan.

While use cases can be recorded on physical paper in the initial stages, an online tool is more suitable for longer-term management of user stories, especially if the team is not co-located.

You can create issues for each of the user stories and use a GitHub Project Board to sort them into categories.

📦 Example Project Board:

📦 Example Issue to represent a user story:

A video on GitHub Project Boards:

📦 Example Google Sheet for recording user stories:

📦 Example Trello Board for recording user stories:

This article by Mike Cohn from MountainGoatSoftware explains how to use user stories to capture NFRs.

Use Cases

Introduction

🏆 Can explain use cases

Use Case: A description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor.[ 📖 : uml-user-guideThe Unified Modeling Language User Guide, 2e, G Booch, J Rumbaugh, and I Jacobson ]

Actor: An actor (in a use case) is a role played by a user. An actor can be a human or another system. Actors are not part of the system; they reside outside the system.

A use case describes an interaction between the user and the system for a specific functionality of the system.

System: ATM Actor: Customer
Use Case: Check account balance
1. User inserts an ATM card
2. ATM prompts for PIN
3. User enters PIN
4. ATM prompts for withdrawal amount
5. User enters the amount
6. ATM ejects the ATM card and issues cash
7. User collects the card and the cash.

System: A Learning Management System (LMS)
Actor: Student
Use Case: Upload file
1. Student requests to upload file
2. LMS requests for the file location
3. Student specifies the file location
4. LMS uploads the file

UML includes a diagram type called use case diagrams that can illustrate use cases of a system visually, providing a visual ‘table of contents’ of the use cases of a system. In the example below, note how use cases are shown as ovals and user roles relevant to each use case are shown as stick figures connected to the corresponding ovals.

Use cases capture the functional requirements of a system.

Identifying

🏆 Can use use cases to list functional requirements of a simple system

A use case is an interaction between a system and its actors.

Actors in Use Cases

Actor: An actor (in a use case) is a role played by a user. An actor can be a human or another system. Actors are not part of the system; they reside outside the system.

📦 Some example actors for a Learning Management System

Actors: Guest, Student, Staff, Admin, ExamSys, LibSys.

A use case can involve multiple actors.

Software System: LearnSys
Use case: UC01 conduct survey
Actors: Staff, Student

An actor can be involved in many use cases.

Software System: LearnSys
Actor: Staff
Use cases: UC01 conduct survey, UC02 Set Up Course Schedule, UC03 Email Class, ...

A single person/system can play many roles.

Software System: LearnSys
Person: a student
Actors (or Roles): Student, Guest, Tutor

Many persons/systems can play a single role.

Software System: LearnSys
Actor(or role) : Student
Persons that can play this role : undergraduate student, graduate student, a staff member doing a part-time course, exchange student

Use cases can be specified at various levels of detail.

📦 Consider the three use cases given below. Clearly, (a) is at a higher level than (b) and (b) is at a higher level than (c).

System: LearnSys
Use cases:
a. Conduct a survey
b. Take the survey
c. Answer survey question

While modeling user-system interactions,

💡 Start with high level use cases and progressively work toward lower level use cases.

💡 Be mindful at which level of details you are working on and not to mix use cases of different levels.

Consider a simple movie ticket vending machine application. Every week, the theatre staff will enter the weekly schedule as well as ticket price for each show. A customer sees the schedule and the ticket price displayed at the machine. There is a slot to insert money, a keypad to enter a code for a movie, a code for the show time, and the number of tickets. A display shows the customer's balance inside the machine. A customer may choose to cancel a transaction before pressing the “buy” button. Printed tickets can be collected from a slot at the bottom of the machine. The machine also displays messages such as "Please enter more money”, “Request fewer tickets" or "SOLD OUT!”. Finally, a "Return Change" button allows the customer to get back his unspent money.

Draw a use case diagram for the above requirements.

Note that most of the details in the description are better given as part of the use case description rather than as low-level use cases in the diagram.

A software house wishes to automate its Quality Assurance division.

The system is to be used by Testers, Programmers and System Administrators. Only an administrator can create new users and assign tasks to programmers. Any tester can create a bug report, as well as set the status of a bug report as ‘closed’. Only a programmer can set the state of a bug report to ‘fixed’, but a programmer cannot set the status of a bug report to ‘closed’. Each tester is assigned just one task at a time. A task involves testing of a particular component for a particular customer. Tester must document the bugs they find. Each bug is given a unique identifier. Other information recorded about the bug is component id, severity, date and time reported, programmer who is assigned to fix it, date fixed, date retested and date closed. The system keeps track of which bugs are assigned to which programmer at any given time. It should be able to generate reports on the number of bugs found, fixed and closed e.g. number of bugs per component and per customer; number of bugs found by a particular tester ; number of bugs awaiting to be fixed; number of bugs awaiting to be retested; number of bugs awaiting to be assigned to programmers etc.

Develop a use case diagram to capture their requirements given below.

Explanation: The given description contains information not relevant to use case modeling. Furthermore, the description is not enough to complete the use case diagram All these are realities of real projects. However, the process of trying to create this use case diagram prompts us to investigate issues such as:

Is ‘edit bug report’ a use case or editing the bug report is covered by other use cases such as those for setting the status of bug reports? If it is indeed a separate use case, who are the actors of that use case?
Does ‘assign task’ simply means ‘assign bug report’ or is there any other type of tasks?
There was some mention about Customers and Components. Does the system have to support use cases for creating and maintaining details about those entities? For example, should we have a ‘create customer record’ use case?
Which actors can perform the ‘generate report’ use case? Are reports generated automatically by the system at a specific time or generated ‘on demand’ when users request to view them? Do we have to treat different types of reports as different use cases (in case some types of reports are restricted to some types of users)? The above diagram assumes (just for illustration) that the report is generated on demand and only the system admin can generate any report.

Details

🏆 Can specify details of a use case in a structured format

Writing use case steps

The main body of the use case is the sequence of steps that describes the interaction between the system and the actors. Each step is given as a simple statement describing who does what.

📦 An example of the main body of a use case.

Student requests to upload file
LMS requests for the file location
Student specifies the file location
LMS uploads the file

A use case describes only the externally visible behavior, not internal details, of a system i.e. should not mention give details that are not part of the interaction between the user and the system.

📦 This example use case step refers to behaviors not externally visible .

LMS saves the file into the cache and indicates success.

A step gives the intention of the actor (not the mechanics). That means UI details are usually omitted. The idea is to leave as much flexibility to the UI designer as possible. That is, the use case specification should be as general as possible (less specific) about the UI.

❌ User right-clicks the text box and chooses ‘clear’ : this contains UI-specific details and is not a good use case step)

✅ User clears the input : this is better because it omits UI-specific details

This is how you can include repetitive steps in a scenario.

Software System: Square game Use case: UC02 - Play a Game Actors: Player (multiple players)

A Player starts the game.
SquareGame asks for player names.
Each Player enters his own name.
SquareGame shows the order of play.
SquareGame prompts for the current Player to throw die.
Current Player adjusts the throw speed.
Current Player triggers the die throw.
Square Game shows the face value of the die.
Square Game moves the Player's piece accordingly.
Steps 5-9 are repeated for each Player, and for as many rounds as required until a Player reaches the 100th square.
Square Game shows the Winner.

Use case ends.

The Main Success Scenario (MSS) describes the most straightforward interaction for a given use case, which assumes that nothing goes wrong. This is also called the Basic Course of Action or the Main Flow of Events of a use case.

System: Online Banking System (OBS)
Use case: UC23 - Transfer Money
Actor: User
MSS:
1. User chooses to transfer money.
2. OBS requests for details of the transfer.
3. User enters the requested details.
4. OBS requests for confirmation.
5. OBS transfers the money and displays the new account balance.
6. Use case ends.

Note how the MSS assumes that all entered details are correct and ignores problems such as timeouts, network outages etc. Fro example, MSS does not tell us what happens if the user enters an incorrect data.

Extensions are "add-on"s to the MSS that describe exceptional/alternative flow of events. They describe variations of the scenario that can happen if certain things are not as expected by the MSS. Extensions appear below the MSS.

📦 This example adds some extensions to the use case in the previous example.

System: Online Banking System (OBS)
Use case: UC23 - Transfer Money
Actor: User
MSS:
1. User chooses to transfer money.
2. OBS requests for details of the transfer.
3. User enters the requested details.
4. OBS requests for confirmation.
5. OBS transfers the money and displays the new account balance.
6. Use case ends.
Extensions:
1. 3a. OBS detects an error in the entered data.
  1. 3a1. OBS requests for the correct data.
  2. 3a2. User enters new data.
  3. Steps 3a1-3a2 are repeated until the data entered are correct.
  4. Use case resumes from step 4.
2. 3b. User requests to effect the transfer in a future date.
  1. 3b1. OBS requests for confirmation.
  2. 3b2. User confirms future transfer.
  3. Use case ends.
3. *a. At any time, User chooses to cancel the transfer.
  1. *a1. OBS requests to confirm the cancellation.
  2. *a2. User confirms the cancellation.
  3. Use case ends.
4. *b. At any time, 120 seconds lapse without any input from the User.
  1. *b1. OBS cancels the transfer.
  2. *b2. OBS informs the User of the cancellation.
  3. Use case ends.

Note that the numbering style is not a universal rule but a widely used convention. Based on that convention,

either of the extensions marked 3a. and 3b. can happen just after step 3 of the MSS.
the extension marked as *a. can happen at any step (hence, the *).

When separating extensions from the MSS, keep in mind that the MSS should be self-contained. That is, the MSS should give us a complete usage scenario.

Also note that it is not useful to mention events such as power failures or system crashes as extensions because the system cannot function beyond such catastrophic failures.

In use case diagrams you can use the << extend >> arrows to show extensions. Note the direction of the arrow is from the extension to the use case it extends and the arrow uses a dashed line.

A use case can include another use case. Underlined text is commonly used to show an inclusion of a use case.

📦 This use case includes two other use cases, one in step 1 and one in step 2.

Software System: LearnSys
Use case: UC01 - Conduct Survey
Actors: Staff, Student
MSS:
1. Staff creates the survey (UC44).
2. Student completes the survey (UC50).
3. Staff views the survey results.
4. Use case ends.

Inclusions are useful,

when you don't want to clutter a use case with too many low-level steps.
when a set of steps is repeated in multiple use cases.

We use a dotted arrow and a << include >> annotation to show use case inclusions in a use case diagram. Note how the arrow direction is different from the << extend >> arrows.

Preconditions specify the specific state we expect the system to be in before the use case starts.

Software System: Online Banking System
Use case: UC23 - Transfer Money
Actor: User
Preconditions: User is logged in.
MSS:
1. User chooses to transfer money.
2. OBS requests for details for the transfer.
3. ...

Guarantees specify what the use case promises to give us at the end of its operation.

Software System: Online Banking System
Use case: UC23 - Transfer Money
Actor: User
Preconditions: User is logged in.
Guarantees:
Money will be deducted from the source account only if the transfer to the destination account is successful
The transfer will not result in the account balance going below the minimum balance required.
MSS:
1. User chooses to transfer money.
2. OBS requests for details for the transfer.
3. ...

Complete the following use case (MSS, extensions, etc.). Note that you should not blindly follow how the existing EZ-Link machine operates because it will prevent you from designing a better system. You should consider all possible extensions without complicating the use case too much.

System: EZ-Link machine
Use case: UC2 top-up EZ-Link card
Actor: EZ-Link card user

System: EZ-Link machine (those found at MRTs)
Use case: UC2 top-up EZ-Link card
Actor: EZ-Link card user
Preconditions: All hardware in working order.
Guarantees: MSS → the card will be topped-up.
MSS:
1. User places the card on the reader.
2. System displays card details and prompts for desired action.
3. User selects top-up.
4. System requests for top-up details (amount, payment option, receipt required?).
5. User enters details.
6. System processes cash payment (UC02) or NETS payment (UC03).
7. System updates the card value.
8. System indicates transaction as completed.
9. If requested in step 5, system prints receipt.
10. User removes the card.
11. Use case ends.
Extensions:
1. *a. User removed card or other hardware error detected.
  1. *a1. System indicates the transaction has been aborted.
  2. Use case ends.

Notes:

We assume that the only way to cancel a transaction is by removing the card.
By not breaking step 4 into further steps, we avoid committing to a particular mechanism to enter data. For example, we are free to accept all data in one screen.
In step 5, we assume that the input mechanism does not allow any incorrect data.

System: EZ-Link machine
Use case: UC03 process NETS payment
Actor: EZ-Link card user
Preconditions: A transaction requiring payment is underway.
Guarantees: MSS → Transaction amount is transferred from user account to EZ-Link company account.
MSS:
1. System requests to insert ATM card.
2. User inserts the ATM card.
3. System requests for PIN.
4. User enters PIN.
5. System reports success.
6. Use case ends.
Extensions:
1. 2a. Unacceptable ATM card (damaged or inserted wrong side up).
  1. ...
2. 4a. Wrong PIN.
  1. ...
3. 4b. Insufficient funds.
  1. ...
4. *a. Connection to the NETS gateway is disrupted.
  1. ...

Note: UC02 can be written along similar lines.

Complete the following use case (MSS, extensions, etc.).

System: LearnSys (an online Learning Management System)
Use case: UC01 reply to post in the forum
Actor: Student

System: LearnSys
Use case: UC01 reply to post in the forum
Actor: Student
Preconditions: Student is logged in and has permission to post in the forum. The post to which the Student replies already exists.
MSS:
1. Student chooses to reply to an existing post.
2. LearnSys requests the user to enter post details.
3. Student enters post details.
4. Student submits the post.
5. LearnSys displays the post.
6. Use case ends.
Extensions:
1. *a. Internet connection goes down.
  1. ...
2. *b. LearnSys times out
  1. ...
3. 3a. Student chooses to ‘preview’ the post.
  1. 3a1. LearnSys shows a preview.
  2. 3a2. User chooses to go back to editing.
  3. Use case resumes at step 3.
4. 3b. Student chooses to attach picture/file
  1. ...
5. 3c. Student chooses to save the post as a draft.
  1. 3c1. LearnSys confirms draft has been saved.
  2. Use case ends.
6. 3d. Student chooses to abort the operation.
  1. ...
7. 4a. The post being replied to is deleted by the owner while the reply is being entered.
  1. ...
8. 4b. Unacceptable data entered.
  1. ...

Which of these cannot appear as part of a use case description?

a. Use case identifier
b. Preconditions
c. Guarantees
d. References to another use case
e. Main Success Scenario
f. Performance requirements
g. Extensions
h. Inclusions

(f)

Explanation: Performance requirements are non-functional requirements. They are not captured in use cases.

Identify problems with this use case description.

System: EZ-Link machine (those found at MRTs)
Use case: UC2 top-up EZ-Link card
Actor: EZ-Link card user
Preconditions: All hardware in working order.
Guarantees: If MSS completes at least until step 7, the card will be topped-up.
MSS:
1. User places the card on the reader.
2. System displays card details and prompts for desired action.
3. User selects top-up.
4. System requests for top-up details (amount, payment option, receipt required?).
5. User enters details.
6. System processes cash payment (UC02) or NETS payment (UC03).
7. System updates the card value.
8. System indicates transaction as completed.
9. If requested in step 5, system prints receipt.
10. User removes the card.
11. Use case ends.
Extensions:
1. *a. User removed card or other hardware error detected.
  1. *a1. System indicates the transaction has been aborted.
  2. Use case ends.

a. It does not consider ‘system crash’ scenario.
b. It does not contain enough UI details.
c. The extension given is in fact an inclusion.
d. No post conditions are given.
e. ‘Use case ends’ is duplicated.

None.

Explanation: Catastrophic failures such as ‘system crash’ need not be included in a use case. A use case is not supposed to contain UI details. Post conditions are optional. It is not a problem to have multiple exit points for a use case.

Usage

🏆 Can optimize the use of use cases

You can use actor generalization in use case diagrams using a symbol similar to that of UML notation for inheritance.

📦 In this example, actor Blogger can do all the use cases the actor Guest can do, as a result of the actor generalization relationship given in the diagram.

Do not over-complicate use case diagrams by trying to include everything possible. A use case diagram is a brief summary of the use cases that is used as a starting point. Details of the use cases can be given in the use case descriptions.

Some include ‘System’ as an actor to indicate that something is done by the system itself without being initiated by a user or an external system.

📦 The diagram below can be used to indicate that the system generates daily reports at midnight.

However, others argue that only use cases providing value to an external user/system should be shown in the use case diagram. For example, they argue that ‘view daily report’ should be the use case and generate daily report is not to be shown in the use case diagram because it is simply something the system has to do to support the view daily report use case.

We recommend that you follow the latter view (i.e. not to use System as a user). Limit use cases for Modeling Behaviors that involve an external actor.

UML is not very specific about the text contents of a use case. Hence, there are many styles for writing use cases. For example, the steps can be written as a continuous paragraph. Use cases should be easy to read. Note that there is no strict rule about writing all details of all steps or a need to use all the elements of a use case.

There are some advantages of documenting system requirements as use cases:

Because they use a simple notation and plain English descriptions, they are easy for users to understand and give feedback.
They decouple user intention from mechanism (note that use cases should not include UI-specific details), allowing the system designers more freedom to optimize how a functionality is provided to a user.
Identifying all possible extensions encourages us to consider all situations that a software product might face during its operation.
Separating typical scenarios from special cases encourages us to optimize the typical scenarios.

One of the main disadvantages of use cases is that they are not good for capturing requirements that does not involve a user interacting with the system. Hence, they should not be used as the sole means to specify requirements.

What are the advantages of using use cases (the textual form) for requirements modelling?

a. They can be fairly detailed but still natural enough for users for users to understand and give feedback.
b. The UI-independent nature of use case specification allows the system designers more freedom to decide how a functionality is provided to a user.
c. Extensions encourage us to consider all situations a software product might face during its operations.
d. They encourage us to identify and optimize the typical scenario of usage over exceptional usage scenarios.

(a) (b) (c) (d)

Which of these are correct?

a. Use case are not very suitable for capturing non-functional requirements.
b. Use case diagrams are less detailed than textual use cases.
c. Use cases are better than user stories.
d. Use cases can be expressed at different levels of abstraction.

(a)(b)(d)

Explanation: It is not correct to say one format is better than the other. It depends on the context.

Glossary

What

🏆 Can explain glossary

Glossary: A glossary serves to ensure that all stakeholders have a common understanding of the noteworthy terms, abbreviation, acronyms etc.

📦 Here is a partial glossary from a variant of the Snakes and Ladders game:

Conditional square: A square that specifies a specific face value which a player has to throw before his/her piece can leave the square.
Normal square: a normal square does not have any conditions, snakes, or ladders in it.

Supplementary Requirements

What

🏆 Can explain supplementary requirements

A supplementary requirements section can be used to capture requirements that do not fit elsewhere. Typically, this is where most Non Functional Requirements will be listed.

Requirements → Requirements →

Non-Functional Requirements

There are two kinds of requirements:

Functional requirements specify what the system should do.
Non-functional requirements specify the constraints under which system is developed and operated.

📦 Some examples of non-functional requirement categories:

Data requirements e.g. size, volatility, persistency etc.,
Environment requirements e.g. technical environment in which system would operate or need to be compatible with.
Accessibility, Capacity, Compliance with regulations, Documentation, Disaster recovery, Efficiency, Extensibility, Fault tolerance, Interoperability, Maintainability, Privacy, Portability, Quality, Reliability, Response time, Robustness, Scalability, Security, Stability, Testability, and more ...

Business/domain rules: e.g. the size of the minefield cannot be smaller than five.
Constraints: e.g. the system should be backward compatible with data produced by earlier versions of the system; system testers are available only during the last month of the project; the total project cost should not exceed $1.5 million.
Technical requirements: e.g. the system should work on both 32-bit and 64-bit environments.
Performance requirements: e.g. the system should respond within two seconds.
Quality requirements: e.g. the system should be usable by a novice who has never carried out an online purchase.
Process requirements: e.g. the project is expected to adhere to a schedule that delivers a feature set every one month.
Notes about project scope: e.g. the product is not required to handle the printing of reports.
Any other noteworthy points: e.g. the game should not use images deemed offensive to those injured in real mine clearing activities.

Non-functional requirements are easier to miss. We should spend extra effort in digging them out as early as possible because sometimes they are critical to the success of the software. E.g. A web application that is too slow or that has low security is unlikely to succeed even if it has all the right functionality.

Given below are some requirements of TEAMMATES (an online peer evaluation system for education). Which one of these are non-functional requirements?

a. The response to any use action should become visible within 5 seconds.
b. The application admin should be able to view a log of user activities.
c. The source code should be open source.
d. A course should be able to have up to 2000 students.
e. As a student user, I can view details of my team members so that I can know who they are.
f. The user interface should be intuitive enough for users who are not IT-savvy.
g. The product is offered as a free online service.

(a)(c)(d)(f)(g)

Explanation: (b) are (e) are functions available for a specific user types. Therefore, they are functional requirements. (a), (c), (d), (f) and (g) are either constraints on functionality or constraints on how the project is done, both of which are considered non-functional requirements.