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=_8975601_1&mode=reset 1/6

MODULE 3.2MODULE 3.2

Requirement documentation

Introduction:

Module 3.2 primarily focuses on the formality of a requirement

speci�cation; speci�cally, we will discuss the essential inclusions of a

8/6/2020 Laureate International Universities

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

software requirement speci�cation.

A typical Software Requirement Speci�cation (SRS) includes the following

inclusions (Wiegers & Beatty, 2013):

1. Introduction

1.1 Purpose

1.2 Document conventions

1.3 Project scope

1.4 References

2. Overall description

2.1 Product perspective

2.2 User classes and characteristics

2.3 Operating environment

2.4 Design and implementation constraints

2.5 Assumptions and dependencies

3. System features

3.x System feature x

3.x.1 Description

3.x.2 Functional requirements

4 Data requirements

4.1 Logical data model

4.2 Data dictionary

4.3 Reports

4.4 Data acquisition, integrity, retention and disposal

5 External interface requirements

5.1 User interfaces

5.2 Software interfaces

5.3 Hardware interfaces

8/6/2020 Laureate International Universities

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

5.4 Communications interfaces

6 Quality attributes

6.1 Usability

6.2 Performance

6.3 Security

6.4 Safety

6.x [others]

7 Internationalisation and localisation requirements

8 Other requirements

Appendix A: Glossary

Appendix B: Analysis models

In Module 2, you learnt a number of characteristics of a good requirement.

For example, a good requirement must be unambiguous, testable

(veri�able), feasible, etc. There are also a number of guidelines for writing

an SRS. The functional requirements can be written from the perspective of

the system or from the user, that is, they can be written in the form of “the

System shall [do something]” or “The user shall [do something]”. You should

always state requirements in a consistent fashion. If a requirement is

written from the system’s perspective, you may use the following template

(Alistair, Wilkinson, Harwood & Novak, 2009):

[optional precondition] [optional trigger event] the system shall [expected

system response]

If a requirement is written from the user’s perspective, you may use the

following template (Ian & Stevens, 2002):

The [user class or actor name] shall be able to [do something] [to some

object] [qualifying conditions, response time, or quality statement]

You will read other guidelines for writing SRS in the Essential Resources.

Reference:

8/6/2020 Laureate International Universities

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

Ian F. A., & Stevens R. (2002). Writing Better Requirements. London: Addison-Wesley.

Alistair M., Wilkinson P., Harwood A., & Novak M. (2009). “EARS (Easy Approach to Requirements Syntax).” In Proceedings of the 17th International Conference on Requirements Engineering, 317–322. Los Alamitos, CA: IEEE Computer Society Press.

Wiegers, K., & Beatty, J. (2013). Software requirements (3rd ed.). Redmond, WA: Microsoft Press.

Essential Resources:

Read Chapter 4 Writing and Reviewing Requirements from

Software requirements

Read Chapter 4 Writing and Reviewing Requirements from

Software requirements. This Chapter looks at the requirements for

requirements and discusses various guidelines for writing software

requirement speci�cation, for example, the language style (4.8) and

the level of detail (4.10).

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

ed.) [4th ed.]. Cham: Springer. doi:10.1007/978-3-319-61073-3

This reference is available from Torrens Library: https://ebookcentral-

proquest-com.ezproxy.laureate.net.au/lib/think/reader.action?

docID=4987067

EARS (Easy Approach to Requirements Syntax) In

Proceedings of the 17th International Conference on

Requirements Engineering, 317–322. Los Alamitos, CA: IEEE

Computer Society Press.

This article discussed requirement syntax for a number of di�erent

types of requirements, for example event-driven requirements, state-

driven requirements. This syntax provides some very good templates

for requirement writing.

8/6/2020 Laureate International Universities

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

This reference is freely available at

https://www.researchgate.net/publication/224079416_Easy_approach_to_

Learning Activity:

Learning Activity: Discussion forum post

Please read the following requirement statements

Statement 1. The System shall allow user to easily download class materials in various format, including MSWord document, PDF and MSPowerpoint.

Statement 2. The System shall allow user to submit assignments before the assignment due date.

Statement 3. The System shall assist students’ learning and increase students’ engagement.

Statement 4. The user can use this system through their web browsers;

Statement 5. The System must response really fast.

Statement 6. The user must be advised of their application status.

Is there any improvement you would make to any of the requirement

statements above? Post your answer to Module 3 discussion forum.

Read other students’ answer and comment on whether you agree or

disagreement with their views. Please provide feedback to at least two

students’ posts.

To participate in the Discussion Forum, click here to scroll to the

bottom of this page then click on the "Module 3 - Discussion

Forum" link.

8/6/2020 Laureate International Universities

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

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.