Requirement management practices

Introduction:

There are four main categories of requirement management practices, they are

· Version control, which includes the designing of a version scheme (e.g. the major/minor version) and tracking requirement versions;

· Change control, which includes proposing changes to requirements, assessing the impact of proposed changes, approving or rejecting changes, update requirements baselines and other related documents;

· Requirements status tracking, which includes defining requirements status, recording updating individual requirement status;

· Requirement tracing, which includes defining and trace links between requirements and other system elements.

In order to effectively manage requirement, each requirement is associated with a number of attributes, for example, the date created, current version, author, priority, status, rationale, validation methods etc.

Version control is critical to requirement management. A simple scheme for version control is the “major.minor” pattern. For example, the first version of a requirement (either an individual requirement or a set of requirements) is Version 1.0. The next version is 1.1 for a minor revision and Version 2.0 for a major revision.

A requirement is moved through a number of status through its lifecycle, for example, they may be proposed, in progress, approved, implemented, verified, or even deferred, deleted or rejected. Recording and maintaining the status of requirement status is also an important requirement management practice.

Essential Resources:

Requirement Management Best Practices

Karl Wiegers is one of the authors of the famous Software Requirements book. In this 1-hour Webinar, Karl discusses the following requirement management best practices:

· Version control of requirements documents

· Change control

· The change control board

· Impact analysis of change requests

· Requirements attributes

· Tracking requirements status

· Requirements traceability

· Using requirements management tools

This is a must-watch video for requirement management.

Wiegers, K. (2017, June). Requirements Management Best Practices Webinar [Video file]. Modern Analyst.com. Retrieved from https://youtu.be/RIHA53SWO20

Best practices for practice management

Read Chapter 6 Best Practices for Requirements Development and Management. This Chapter lists 30 best practices for practice management.

Young, R. R. (2004). The Requirements Engineering Handbook. Boston: Artech House, Inc. Retrieved from http://search.ebscohost.com.ezproxy.laureate.net.au/login.aspx?direct=true&db=nlebk&AN=104655&site=ehost-live

Use version control

This article discusses version control for documents in general. It talks about the definition of version control, the dos and don’ts for version control. A good read for document version control.

The Chartered institute for IT. Tip: Use version control. Retrieved from https://www.bcs.org/content/ConWebDoc/10765

Change Management and tools for requirements engineering

Introduction:

Changes to requirements is inevitable in software engineering. Changes may arise from, for example, changed market environment, policies and procedures, or shifts or changes in business needs. Effective change management is an integral part of requirement management.

You will study the concept of scope creep and the technique for avoiding and controlling scope creep. It is important to understand that changes need to be put through a formal process, for example, proposing a change, assessing change requests, making decisions, implementing the changes, and verify the changes. The status of a change will also need to be recorded and maintained, for example, proposed, rejected, approved, in progress, implemented, verified, or cancelled.

A board of people are convened to make decisions to changes to requirements baseline. The board normally consists of a wide range of expertise, for example, project management, business analysts, developers, testers, technical supports, in order to accurately assess the impact of changes.

You will study a few change management tools and the procedure of impact analysis.

Essential Resources:

Requirement traceability

Read Chapter 7 Advanced Traceability in Requirement engineering. (page 159 – 186). This Chapter providers a comprehensive discussion on requirement traceability.

Dick, J., Hull, E., & Jackson, K. (2017). Requirements engineering. Springer. Switzerland, Cham. Retrieved from https://ebookcentral-proquest-com.ezproxy.laureate.net.au/lib/think/detail.action?docID=4987067

A requirement tool

Read Chapter 8 DOORS: A tool to manage requirements in Requirement engineering. (page 187 – 206). This Chapter presents an overview of one of the requirement management tools – IBM Rational® DOORS® Next Generation.

Dick, J., Hull, E., & Jackson, K. (2017). Requirements engineering. Springer. Switzerland, Cham. Retrieved from https://ebookcentral-proquest-com.ezproxy.laureate.net.au/lib/think/detail.action?docID=4987067

Requirement management

Read Chapter 9 Management Aspects of Requirements Engineering in Requirement engineering. (page 207 – 230). This Chapter discusses a number of management aspects of requirement engineering.

Dick, J., Hull, E., & Jackson, K. (2017). Requirements engineering. Springer. Switzerland, Cham. Retrieved from https://ebookcentral-proquest-com.ezproxy.laureate.net.au/lib/think/detail.action?docID=4987067

Requirements for specific project classes

Introduction:

Requirements practices may need to be adapted in different types of projects. Business analysts should have the flexibility to tailor requirement practices to fit different types of project. The requirement practices in a outsourced project may not be the same as those in a packaged solution project. Module 5.2 looks at a particular class of project – Agile project.

The traditional waterfall development method is a sequential model, that is, project moves through a number of pre-defined stages. It is very expensive, though possible, to move backwards in the project lifecycle, hence the name “waterfall”. Customers are engaged upfront in the requirement elicitation phase of a project. After requirement analysis, specification, validation, customers are required to sign off a software requirement specification. The specification will then be fed into design, development, testing phase. Customers will then be engaged in the final delivery stage of the project.

However, the waterfall development model has a number of limitations and has led to a very high failure rate among the software development projects. For example, different from a construction project where customer can visualise the progress of the product, customers in software development projects have a tendency to change requirement as they cannot see the architecture and the development of software. The inflexibility of waterfall development model requires the requirements to be frozen before they are passed to the software designer and developers and therefore incapable of coping with requirement changes.

Agile development method seeks to address the limitations of waterfall model. Both methods handle requirements differently in various aspects. You will read about the agile development method first, e.g. its manifesto, and learn how requirement practices can be tailored in an agile project.

Essential Resources:

Manifesto for Agile Software Development

Read the manifesto for Agile Software Development at https://agilemanifesto.org and the 12 principles behind the Agile Manifesto at: https://agilemanifesto.org/principles.html

The values and principles in the Agile Software Development Manifesto are discussed in the next Essential Resource.

Selected videos from the Agile Foundations Course on Linda.com.

View the following videos from the Agile Foundations Course on Linda.com.

· The agile manifesto: Values (3m 20s): https://www.lynda.com/Project-Management-tutorials/agile-manifesto-Values/761929/5011070-4.html?org=think.edu.au

· The agile manifesto: Principles (3m 20s): https://www.lynda.com/Project-Management-tutorials/agile-manifesto-Principles/761929/5011071-4.html?org=think.edu.au

· User stories (3m 5s): https://www.lynda.com/Project-Management-tutorials/User-stories/761929/5011078-4.html?org=think.edu.au

· User stories: Common challenges (2m 3s): https://www.lynda.com/Project-Management-tutorials/User-stories-Common-challenges/761929/5011079-4.html?org=think.edu.au

These four videos contain an introduction to the values and principles of the agile manifesto as well as the user stories, an approach commonly adopted in agile project. 

Schön, E., Thomaschewski, J., & Escalona, M. (2017). Agile requirements engineering: A systematic literature review. Computer Standards & Interfaces, 49, 79-91. doi:10.1016/j.csi.2016.08.011

This article is a recent literature review on Agile requirement engineering – the state-of-the-art requirement practices in agile project. This article is available from Torrens library at: https://lesa.on.worldcat.org/oclc/6812611139

Requirements reuse

Introduction:

Wieger and Beatty (2013) identified three dimensions of requirement reuse. They are the extent of reuse, the extent of modification 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:

· Individual requirement statement

· Requirement plus its attributes

· Requirement plus its attributes, context, and associated information such as data definitions, glossary definitions, 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 fill in the gaps. Choosing the right level of abstraction is the key to requirement reuse.

Wingers and Beatty also identified 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.

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_x264.mp4

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 effective reuse-based requirements process. Computer Systems Science and Engineering, 23(6), 373. Retrieved from https://www.researchgate.net/profile/Joaquin_Nicolas/publication/287002917_Eight_key_issues_for_an_effective_reuse-based_requirements_process/links/5734ad7908ae298602ded00a/Eight-key-issues-for-an-effective-reuse-based-requirements-process.pdf

This paper identified eight key issues to be considered for an effective and practical reuse-based requirements engineering process. The key issues are presented in section 3 of this paper.

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/Chernak_Requirements_Reuse.pdf

This paper explored the state of the practice of requirements reuse (in 2012). Although this paper is not recent, Section 4 Reuse Importance, Benefits and Obstacles, Section 5 Reuse Adoption Factors and Section 6 Reuse Effectiveness Factors are still relevant.