Three- Reflective Journal

8/6/2020 Laureate International Universities

https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975600_1&mode=reset 1/7

MODULE 2.1MODULE 2.1

Levels and types of requirements and characteristics of good

requirements

Introduction:

You have learnt from Module 1 that requirement is “a statement that

identi�es a product or process operational, functional, or design

characteristic or constrain, which is unambiguous testable or measurable,

and necessary for product or process acceptability” (Dick, Hull & Jackson,

2017). It is important to note that requirements can be categorised into

8/6/2020 Laureate International Universities

https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975600_1&mode=reset 2/7

di�erent types. Take Blackboard for example, compare the following two

requirements:

Requirement 1: This System will enable students to view learning activities;

Requirement 2: This System will be reliable and robust. (Note: this is not an example of a good requirement, but it serves the purpose of demonstrating various types of requirements).

Requirement 1 and 2 do not appear to describe the same aspect of the

System. Requirement 1 is concerned with WHAT the System shall do – its

functionalities, that is, what users (or actors in this System) can accomplish

with this System. Requirement 2, on the other hand, is concerned with HOW

the System shall perform its various tasks. Requirement 2, in a very loose

language, requires the System not to fail every so often.

You should be aware that there is no consensus as to a single taxonomy of

requirement, that is, a requirement may belong to multiple types depending

on the ways requirements are categorised. Young (2004) provides a

requirement analyst’s view of many of the types of requirement. You are

expected to read an extract of Young (2004) (refer to Essential Resources 1).

Among various types of requirements, you are expected to understand the

de�nition and examples of the following:

Business requirement;

User requirements;

High-level or System-level requirements;

Functional requirement;

Non-functional requirement;

Performance requirements;

Interface requirements;

You will also need to familiarise yourself with FURPS and FURPS+. Both

acronyms refer to a set of requirement categories; the latter is an extension

8/6/2020 Laureate International Universities

https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975600_1&mode=reset 3/7

of the former. Refer to Essential Resources 3.

The quality of requirement should not be overlooked. What are the

characteristics of a good requirement? Consider the following requirement

statement:

“The System shall handle many transactions per second.”

That requirement cannot be regarded as a good requirement because,

among many other things, it is not veri�able/testable. What does it mean

many? How many transactions is many? Such requirement engender

confusion and much necessary debate in the later stage of development.

What are the criteria for a requirement to be good? Good requirements

should have the following characteristics:

Unambiguous

Testable (veri�able)

Clear (concise, terse, simple, precise)

Correct

Understandable

Feasible (realistic, possible)

Independent

Atomic

Necessary

Implementation-free (abstract)

Consistent

Nonredundant

Complete

You need to read Essential Resources 4, which discusses each of the

criterion in depth.   

Reference:

8/6/2020 Laureate International Universities

https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975600_1&mode=reset 4/7

Dick, J., Hull, E., & Jackson, K. (2017). Requirements engineering. Springer.

Young, R. (2004). The requirements engineering handbook (Artech house technology management and professional development library). Boston: Artech House.

Essential Resources:

Young, R. (2004). The requirements engineering handbook

(Artech house technology management and professional

development library). Boston: Artech House. Retrieved from:

https://lesa.on.worldcat.org/oclc/54703038

Read extract from The requirements engineering handbook

Read Chapter 4, page 45 – 60. In this short reading, you are introduced

to a few requirement taxonomies and a wide range of requirement

types. You should pay particular attention to the following types of

requirement:

Business rules;

User requirements;

High-level or System-level requirements;

Functional requirements;

Non-functional requirements;

Performance requirements;

Interface requirements;

Product requirements;

On page 56 and Table 4.3 (a-d), Young provided examples of the

requirements types discussed this Chapter. These examples will help

you understand the otherwise abstract de�nitions and descriptions of

requirement types.

On page 53 – 54 under the heading “The ‘Ilities’ and Specialty

Engineering Requirement”, Young provided a list of quality attributes,

for example,

8/6/2020 Laureate International Universities

https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975600_1&mode=reset 5/7

Reliability;

Testability;

Maintainability;

Unfortunately, Young did not provide any further explanations as to

the meanings of those “-ability” quality attributes. You will explore the

de�nitions of those attributes in a subsequent Essential Resources.

YouTube. (2019). What is a Functional Requirement? -

Construx Brain Cast. [online] Available at:

https://www.youtube.com/watch?v=wbCAiLzOE30 [Accessed 24 Jun.

2019].

This short video explains what a functional requirement is in simple

and non-technical language.

Stephens, R. (2015). Beginning software engineering (Wrox:

programmer to programmer). Indianapolis, IN: John Wiley &

Sons. (2015). Retrieved from: https://ebookcentral-proquest-

com.ezproxy.laureate.net.au/lib/think/reader.action?docID=1895174

Read Chapter 4 Requirement Categories Section, page 61 – 67. This

reading is complementary to Learning Activity 1. Pay particular

attention to FURPS and FURPS+ (the list on page 66). Make sure you

understand the de�nition of each requirement category listed on page

66 and are able to give examples of each requirement category in

relation to a concreate information system.

Zielczynski, P. (2019). Requirements Management Using IBM

Rational RequisitePro | 1.1 De�nition of a Requirement and

a Stakeholder | InformIT. [online] Informit.com. Available at:

http://www.informit.com/articles/article.aspx?p=1152528&seqNum=4.

[Accessed 24 Jun. 2019].

8/6/2020 Laureate International Universities

https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975600_1&mode=reset 6/7

Read Chapter 1.4 in Requirement Management Using IBM Rational

RequisitePro

Learning Activity:

Collaborative learning activity:

Once you have read/viewed all essential resources in

Module 2.1, you should have a very good idea of the various types of

requirements and the characteristics of a good requirement. Now

re�ecting on your experience with Blackboard and pretending you are

to develop a System, Whiteboard, exactly the same as Blackboard, list

Three di�erent functional requirements. What Whiteboard should do?

One requirement regarding reliability. How reliable Whiteboard should be?

One performance requirement. How e�cient Whiteboard should be?

One design constraint.

One supportability requirement. How easy should Whiteboard be to support?

One physical requirement.

Bring your list of requirements to the facilitated class and exchange it

with a peer student. Review the other student’s list of requirements,

provide constructive feedback as to:

whether the requirements are correctly categorised;

whether each of the requirements meet the “good” requirement criteria, particular, they are

unambiguous

testable (veri�able)

clear (concise, terse, simple, precise)

8/6/2020 Laureate International Universities

https://laureate-au.blackboard.com/webapps/blackboard/content/listContent.jsp?course_id=_89880_1&content_id=_8975600_1&mode=reset 7/7

correct

understandable

feasible (realistic, possible)

independent

atomic

necessary

implementation-free (abstract)

Provide your feedback both verbally and in writing to your peer.

Note: The Learning activities above are not part of summative/graded

assessment; however they are designed to prepare you for incremental

graded assessment and expand your learning.

These activities encourage a community learning experience between peers,

and provide opportunities for facilitators to o�er formative feedback,

throughout a module, to the student cohort.