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=_8975603_1&mode=reset 1/5

MODULE 5.1MODULE 5.1

Requirements reuse

Source: https://www.modernrequirements.com/industry/services-and-

technology-providers/

Introduction:

Wieger and Beatty (2013) identi�ed three dimensions of requirement reuse.

They are the extent of reuse, the extent of modi�cation and reuse

mechanism. For each of the three dimensions, there are a number of

options or types for requirements reuse. For example, the following options

show a varying extent of reuse:

8/6/2020 Laureate International Universities

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

Individual requirement statement

Requirement plus its attributes

Requirement plus its attributes, context, and associated information such as data de�nitions, glossary de�nitions, acceptance tests, assumptions, constraints, and business rules

A set of related requirements

A set of requirements and their associated design elements

A set of requirements and their associated design, code, and test elements

One option has a greater extent of reuse than the one above it.

Like writing code for software, it is important to bear in mind the reusability

of requirement when developing and specifying requirements for a project.

Well written requirements are easier to be reused. Generic requirement

statements may have more opportunity to be reused, however, overly

generic requirements will not save much of a business analyst’s time as they

will still need to �ll in the gaps. Choosing the right level of abstraction is the

key to requirement reuse.

Wingers and Beatty also identi�ed a number of requirement reuse barriers.

For example, “NIH” and “NAH” syndromes are both considered requirement

reuse barrier. NIH stands for Not Invented Here. This refers to the tendency

for business analysts to always reinvented wheel for the project at hand and

unwillingness to use generic requirement developed elsewhere. NAH stands

for Not Applicable Here. This refers to the over stress on the uniqueness of

the project at hand, the non-acceptive  attitude towards business process or

approach in other projects.

Reference:

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

WA: Microsoft Press.

8/6/2020 Laureate International Universities

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

Essential Resources:

Requirements Reuse: Fantasy or Feasible?

Karl provided a very comprehensive introduction to

requirements reuse. This video can be access at:

http://videos.itmpi.org/2013/mp4/Wiegers_20130906_RequirementsReuse

This is a must-watch video on requirements reuse. The presenter is

one of the authors of Software requirements, Karl Wieger. In this 73-

minute video, Karl discussed:

Why reuse requirements?

Dimensions of requirements reuse

What information to reuse

Common reuse scenarios

Making requirements reusable

Reuse barriers and success factors

Getter star4ted with reuse

Toval, A., Moros, B., Nicolas, J., & Lasheras, J. (2008). Eight key

issues for an e�ective reuse-based requirements process.

Computer Systems Science and Engineering, 23(6), 373.

Retrieved from

https://www.researchgate.net/pro�le/Joaquin_Nicolas/publication/287002

based_requirements_process/links/5734ad7908ae298602ded00a/Eight-

key-issues-for-an-e�ective-reuse-based-requirements-process.pdf

This paper identi�ed eight key issues to be considered for an e�ective

and practical reuse-based requirements engineering process. The key

issues are presented in section 3 of this paper.

8/6/2020 Laureate International Universities

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

Chernak, Y. (2012, June). Requirements reuse: the state of

the practice. In 2012 IEEE International Conference on

Software Science, Technology and Engineering (pp. 46-53).

IEEE. Retrieved from

https://www.modernanalyst.com/Portals/0/Public%20Uploads%203/Chern

This paper explored the state of the practice of requirements reuse (in

2012). Although this paper is not recent, Section 4 Reuse Importance,

Bene�ts and Obstacles, Section 5 Reuse Adoption Factors and Section

6 Reuse E�ectiveness Factors are still relevant.

Learning Activity:

Collaborative learning activity

In the facilitated learning sessions, discuss within your

assessment group, examine the case study you completed in the

previous assessment to see if you can simplify requirements and

reuse requirements from other projects.

Analyse your requirement statements in the �rst two assessments

you wrote for the case study. Assess the extension of reuse for each

requirement. Are the requirements easy to be reused in a di�erent

project?

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.

8/6/2020 Laureate International Universities

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