Chapter 3

Software Requirements and Modelling

Software Requirements and Modelling
3.1. Objectives:
By the end of the course the student(s) should be able to conduct Software Development
activities in line with user requirements
3.2. Outline Challenges in Requirements Determination
Requirements are the functionalities required in a system. Determining the exact
requirements for a system has a lot of challenges that include the following:
1. Communication barriers existing between the analyst and client in terms of language
and expectations.
2. Understanding large and complex system requirements is difficult at times for both
technical and non-technical stakeholders
3. Difficulty in defining system boundaries - user many include several unrelated and
unnecessary functions besides the important ones
4. Difficulty in partitioning the system suitably to reduce complexity
5. Conflicting requirements are there – stakeholders may have different demands.
6. Volatile requirements
7. Difficult to validating and trace requirements – forward and backward traceability.
8. Difficult to identify and prioritize critical requirements
9. Difficulty in proper documentation, scheduling meeting time and budget constraints
10. Stakeholder resistance to change

Table 1 concludes these characters of previously discussed six requirements

determination methods.
Table 1
Characteristic Interviews Questionnair Observation Document JAD Prototyping
es analysis
Information High Medium to High Low High Medium to
Richness low (passive) & High
old
Time Required Can be Low to Can be Low to Dedicated Moderate
extensive moderate extensive moderate period of and can be
time of all extensive
kinds of
involved
people
Expense Can be high Moderate Can be high Low to High High
moderate
Chance for Good Limited Good Limited Good Good
Follow-up and
probing
Confidentiality Interviewee is Respondent Observee is Depends on All the people Usually know
known to can be known to nature of know each each other
interviewer unknown interviewer document other
Involvement of Interviewee is Respondent is Interviewees None, no All kinds of Users are
Subject involved and passive, no may or may clear people are involved and
committed clear not be involved commitmen involved and committed
commitment and committed t committed
depending on
whether they
know if they
are being
observed
Potential Limited Can be quite Limited Potentially Potentially Limited
Audience numbers, but large, but lack numbers and biased by biased by the numbers; it is
complete of response limited time of which subordinator difficult to
responses from some each documents intentionally diffuse or
from those can bias were kept or don’t want to adapt to
interviewed results because directly point other
document out his potential
not created superior’s users
for this errors.
purpose
3.3. Produce Requirements Elicitation and Traceability
Documents
Requirements traceability is concerned with documenting the life of a requirement. It should
be possible to trace back to the origin of each requirement and every change made to the
requirement should therefore be documented in order to achieve traceability. Traceability
should span the whole life cycle’s phases.
A traceability document is any textual, or model item, which needs to be explicitly traced
from another textual, or model item, in order to keep track of the dependencies between
them.
Implicit Traceability
1. Naming conventions
2. The construction of mappings between the models
3. Relationships between the model items themselves
4. The creation of different perspectives illustrating how the elements of one model
satisfy the demands implicit in the elements of another model
The figure below shows the models and the implicit relationships between these models.
The relationship between the models provides a level of traceability that is implicit to the
development process.

These implicit relationships are fundamental to the development process and benefit from
being built as a natural part of the developer’s work. These relationships are central to the
modelling process and are constructed, and maintained, as the models are matured. The
implicit traceability is limited to the relationships available in our modelling notation.
Explicit Traceability
So why would we want any additional explicit traceability?
We are to adopt the principles of requirements traceability we would need to integrate the
Requirements, model items and other traceability items into a traceability hierarchy. We
may also want to add additional traceability relationships into our development process.
The following figure shows an example traceability hierarchy showing the relationship
between "features"
defined in a vision
document and
"software
requirements" defined
in a use case model and
a supplementary
specification. It also
shows how the
software requirements
are traced into the Test
Requirements, Design
and User
Documentation
Sample Requirements Structure

Other examples include the relationships between:

• the features of the system and the use case model
• the use case model and the user documentation
• the use case model and the test requirements
There are three types of traceability information that may be maintained:
1. Source traceability information links the requirements to the stakeholders who
proposed the requirements and to the rationale for these requirements. When a
change is proposed, you use this information to discover the stakeholders so that
they can be consulted about the change.
2. Requirements traceability information links dependent requirements within the
requirements document. You use this information to assess how many requirements
are likely to be affected by a proposed change and the extent of consequential
requirements changes that may be necessary.
3. Design traceability information links the requirements to the design modules where
these requirements are implemented. You use this information to assess the impact
of proposed requirements changes on the system design and implementation.
Traceability types:
1. Forward Traceability: This document is used to map the requirements to the test
cases. This will help you in ensuring that your project is moving in the right
direction. It will also ensure that all the requirements are tested thoroughly.
2. Backward Traceability: When you map your test cases with the requirements, you
will be creating a Backward Traceability Matrix. This will help you in making sure
that you are not expanding the scope of the project by adding features or
functionality that was not a part of the original requirements.
3. Bidirectional Traceability: When you are mapping the requirements to test cases
for Forward traceability and test cases to requirements for backward traceability in
a single document, it is called a Bidirectional Traceability Matrix. This document
will help you in ensuring that all the specified requirements have corresponding
test cases and vice versa.
The examples show forward and backward tracing between user and system requirements.
User requirement identifiers begin with "U" and system requirements with "S." Tracing S12
to its source makes it clear this requirement is erroneous: it must be eliminated, rewritten,
or the traceability corrected.

As described in ISO/IEC 29110, a traceability matrix is developed to connect the

requirements, to the architecture, to the software components and to the tests. One
advantage of a traceability matrix is the rapid identification of the software components
impacted when requirements are modified, added, or deleted during a project. A fragment
of a traceability matrix is presented in Table 5.
Table 5: Traceability Matrix

In addition to the documents required by ISO/IEC 29110, students have to produce a lessons
learned report and an analysis of the metrics collected. This report captures, from their
point of view, what went well, what could have been done better and what surprised them
during the 10-week project.
3.4. Develop User and System Requirements Documents using
Appropriate Tools

3.4.1. Assess Feasibility of a System Requirements

System requirements are assessed to determine whether the proposed system can
effectively operate on the given system specification. Assessing technical feasibility includes
evaluating the ability of computer hardware and software to handle workloads adequately.
If the requirements cannot be met, then the project needs to determine if the requirements
should be modified, or if another technology is more appropriate. The feasibility assessment
process includes the following steps. The information produced by the assessment process
should be documented in a report.
1. Does the infrastructure design meet the need specified during the Identification
Phase?
2. Are the engineering and architectural requirements of the project achievable? If so,
are they achievable at a price comparable with similar infrastructure?
3. Can the service be specified in terms of outputs? If so, can the service be measured
adequately though performance indicators?
4. Can the main technological changes in the service delivery be satisfactorily
estimated?
5. Assess the probability that the requirements can be met by the chosen technology.
Consider whether the design will reach any technical limitations, such as number of
gates, complexity, operating frequency, and packaging limitations (e.g. number of
pins).
6. Check the availability of the selected technology. Consider how long the chip and
tools will be supported, in relation to mission duration. When will the parts become
obsolete? Also consider the availability of technical support.
7. Estimate the design complexity
8. Estimate the power consumption
9. Perform a preliminary timing analysis to assess the feasibility of speed requirements
10. Are safety and security issues covered?
11. Select a production test approach and verify feasibility against all requirements
12. Identify and evaluate suitability and qualification status of complex electronic
technologies
13. Identify suitable packaging; make a baseline selection
14. Determine availability and status of design and test tools and libraries and necessary
personnel

Requirements are best determined by systems analysts and business people together
Strategies for analyzing the requirements:
 Business Process Analysis (BPA)
 Business Process Improvement (BPI)
 Business Process Reengineering (BPR)

Techniques for identifying requirements:

 Interviews, questionnaires and/or observation
 Joint application development (JAD)
 Document analysis
3.4.2. Review the Requirements Document

A formal review is conducted with all parties involved. The review serves two purposes:
1. To substantiate the thoroughness and accuracy of the Feasibility Study
2. To make a project decision - either approve it, reject it, or ask that it be revised
before making a final decision. If approved, it is very important that all parties sign
the document which expresses their acceptance and commitment to it. If the
Feasibility Study is rejected, the reasons for its rejection should be explained and
attached to the document.
It is often useful to examine each requirement against a set of checklist questions. Here is a
small subset of those that might be asked:
1. Are requirements stated clearly? Can they be misinterpreted?
2. Is the source (e.g., a person, a regulation, a document) of the requirement
identified? Has the final statement of the requirement been examined by or against
the original source?
3. Is the requirement bounded in quantitative terms?
4. What other requirements relate to this requirement? Are they clearly noted via a
cross-reference matrix or other mechanism?
5. Does the requirement violate any system domain constraints?
6. Is the requirement testable? If so, can we specify tests (sometimes called validation
criteria) to exercise the requirement?
7. Is the requirement traceable to any system model that has been created?
8. Is the requirement traceable to overall system/product objectives?
9. Is the specification structured in a way that leads to easy understanding, easy
reference, and easy translation into more technical work products?
10. Has an index for the specification been created?
11. Have requirements associated with performance, behaviour, and operational
characteristics been clearly stated? What requirements appear to be implicit?
Requirements validation determines whether the requirements are substantial to design the
system. The problems encountered during requirements validation are listed below.
1. Unclear stated requirements
2. Conflicting requirements are not detected during requirements analysis
3. Errors in the requirements elicitation and analysis
4. Lack of conformance to quality standards.
To avoid the problems stated above, a requirements review is conducted, which consists of
a review team that performs a systematic analysis of the requirements. The review team
consists of software engineers, users, and other stakeholders who examine the specification
to ensure that the problems associated with consistency, omissions, and errors are detected
and corrected. In addition, the review team checks whether the work products produced
during the requirements phase conform to the standards specified for the process, project,
and the product.
At the review meeting, each participant goes over the requirements before the meeting
starts and marks the items which are dubious or need clarification. Checklists are often used
for identifying such items. Checklists ensure that no source of errors, whether major or
minor, is overlooked by the reviewers.
A 'good' checklist consists of the following:
1. Is the initial state of the system defined?
2. Is there a conflict between one requirement and the other?
3. Are all requirements specified at the appropriate level of abstraction?
4. Is the requirement necessary or does it represent an add-on feature that may not be
essentially implemented?
5. Is the requirement bounded and has a clear defined meaning?
6. Is each requirement feasible in the technical environment where the product or
system is to be used?
7. Is testing possible once the requirement is implemented?
8. Are requirements associated with performance, behaviour, and operational
characteristics clearly stated?
9. Are requirements patterns used to simplify the requirements model?
10. Are the requirements consistent with the overall objective specified for the
system/product?
11. Have all hardware resources been defined?
12. Is the provision for possible future modifications specified?
13. Are functions included as desired by the user (and stakeholder)?
14. Can the requirements be implemented in the available budget and technology?
15. Are the resources of requirements or any system model (created) stated clearly?
The checklists ensure that the requirements reflect users' needs and provide groundwork for
design. Using the checklists, the participants specify the list of potential errors they have
uncovered. Lastly, the requirements analyst either agrees to the presence of errors or states
that no errors exist.
3.4.3. Validate the Requirement

The primary goal of systems engineering (SE) is to develop a solution that meets the needs
and requirements of stakeholders. Validation is the process by which engineers ensure that
the system will meet these needs and requirements.
A validation action is defined and then performed (see Figure, below).

Definition and Usage of a Validation Action. (SEBoK Original)

A validation action applied to an engineering element includes the following:

 Identification of the element on which the validation action will be performed.
 Identification of the reference that defines the expected result of the validation
action.
Performing the validation action includes the following:
 Obtaining a result by performing the validation action onto the submitted element.
 Comparing the obtained result with the expected result.
 Deducing the degree of compliance of the element.
 Deciding on the acceptability of this compliance, because sometimes the result of
the comparison may require a value judgment to decide whether to accept the
obtained result as compared to the relevance of the context of use.
Note: If there is uncertainty about compliance, the cause could come from ambiguity in the
requirements.
Program testing, where the system is executed using simulated test data, is the principal
validation technique. Validation may also involve checking processes, such as inspections
and reviews, at each stage of the software process from user requirements definition to
program development. Because of the predominance of testing, the majority of validation
costs are incurred during and after implementation.
What to Validate?
Any engineering element can be validated using a specific reference for comparison, such as
stakeholder requirements, system requirements, functions, system elements, documents,
etc. Examples are provided in Table below:

Examples of Validated Items (SEBoK Original)

Items Explanation for Validation

Document To validate a document is to make sure its content is compliant with the
inputs of the task that produced the document.
Stakeholder To validate a stakeholder requirement is to make sure its content is justified
Requirement and relevant to stakeholders' expectations, complete and expressed in the
and System language of the customer or end user. To validate a system requirement is to
Requirement make sure its content translates correctly and/or accurately a stakeholder
requirement to the language of the supplier.
Design To validate the design of a system (logical and physical architectures) is to
demonstrate that it satisfies its system requirements.
System To validate a system (product, service, or enterprise) is to demonstrate that
the product, service, or enterprise satisfies its system requirements and/or its
stakeholder requirements.
Activity To validate an activity or a task is to make sure its outputs are compliant with
its inputs.
Process To validate a process is to make sure its outcomes are compliant with its
purpose.

Activities of the Validation Process

Major activities and tasks performed during this process include the following:
1. Establish a validation strategy (often drafted in a validation plan). This activity is
carried out concurrently to system definition activities:
a. Identify the validation scope that is represented by (system and/or
stakeholder) requirements; normally, every requirement should be checked
as the number of validation actions can be high.
b. Identify constraints according to their origin (technical feasibility,
management constraints as cost, time, availability of validation means or
qualified personnel, and contractual constraints that are critical to the
mission) that limit or increase potential validation actions.
c. Define appropriate verification/validation techniques to be applied, such as
inspection, analysis, simulation, review, testing, etc., depending on the best
step of the project to perform every validation action according to
constraints.
d. Consider a trade-off of what should be validated (scope) while taking into
account all constraints or limits and deduce what can be validated
objectively; selection of validation actions would be made according to the
type of system, objectives of the project, acceptable risks, and constraints.
e. Optimize the validation strategy to define the most appropriate validation
technique for every validation action, define necessary validation means
(tools, test-benches, personnel, location, and facilities) according to the
selected validation technique, schedule the execution of validation actions
in the project steps or milestones, and define the configuration of elements
submitted to validation actions (this is primarily about testing on physical
elements).
 2. Perform validation actions, including the following tasks:
a. Detail each validation action. In particular, note the expected results, the
validation technique to be applied, and the corresponding means necessary
(equipment, resources, and qualified personnel).
b. Acquire validation means used during the system definition steps (qualified
personnel, modelling tools, mocks-up, simulators, and facilities), then those
means used during integration and final and operational steps (qualified
personnel, validation tools, measuring equipment, facilities, validation
procedures, etc.).
c. Carry out validation procedures at the right time, in the expected
environment, with the expected means, tools, and techniques.
d. Capture and record results obtained when performing validation actions
using validation procedures and means.
3. Analyze the obtained results and compare them to the expected results. Decide if
they comply acceptably. Record whether the decision and status are compliant or
not, and generate validation reports and potential issue/trouble reports, as well as
change requests on (system or stakeholder) requirements as necessary.
4. Control the process using following tasks:
a. Update the validation plan according to the progress of the project; in
particular, planned validation actions can be redefined because of
unexpected events.
b. Coordinate validation activities with the project manager regarding the
schedule, acquisition of means, personnel, and resources. Coordinate with
the designers for issue/trouble/non-conformance reports. Coordinate with
the configuration manager for versions of physical elements, design
baselines, etc.

Other Requirements Validation Techniques

A number of other requirements validation techniques are used either individually or in
conjunction with other techniques to check the entire system or parts of the system. The
selection of the validation technique depends on the appropriateness and the size of the
system to be developed. Some of these techniques are listed below:
1. Test case generation: The requirements specified in the SRS document should be
testable. The test in the validation process can reveal problems in the requirement.
In some cases test becomes difficult to design, which implies that the requirement is
difficult to implement and requires improvement.
2. Automated consistency analysis: If the requirements are expressed in the form of
structured or formal notations, then CASE tools can be used to check the
consistency of the system. A requirements database is created using a CASE tool that
checks the entire requirements in the database using rules of method or notation.
The report of all inconsistencies is identified and managed.
3. Prototyping: Prototyping is normally used for validating and eliciting new
requirements of the system. This helps to interpret assumptions and provide an
appropriate feedback about the requirements to the user. For example, if users have
approved a prototype, which consists of graphical user interface, then the user
interface can be considered validated.
3.4.4. Compile the Software Requirements Specification Document

How to Build Software Requirement Specifications

Since 1998, the IEEE template for writing software specification requirements has been used
across numerous industries. Some of the most common templates today use the standard
language and incremental set-up found in module five of the ISO/IEC/IEEE 29148 which
includes:
1. Introduction: This area includes scope, purpose, definitions, references, and an
overview.
2. Overall Description: Document the areas of product perspective and functionality,
user characteristics, constraining elements (such as assumptions and dependencies),
and apportionment of requirements in this section.
3. Specific Requirements (the largest and most important area): Include all the
requirements, functions, interfaces, performance and data requirements, design
constraints, security, adjustments needed for site implementation, maintenance,
features and systems attributes, priorities, and release plans.
4. Supporting Information: Include any Indexes, graphs, appendices, and special
instructions not already covered in this section.
Although all areas of the SRS have equal value, in the actual outline it is estimated
that you should devote about one-quarter of the time to the Specific Requirements
section with emphasis on how to prioritize functions and requirements, validation,
and testing for release.

Another Perspective of an SRS

The purpose specifies the context and intended audience of the SRS. The scope
names the software product that is being specified, the high level benefits /
objectives/goals of the product (which may be a reference to and/or summary of a
different document, such as a vision and scope document). The definitions section
defines all terms and abbreviations that a reader must know in order to
understand the document. Finally, the overview descriptions the rest of the
content of the SRS and how it is organized. Some people choose to put definitions
and references into appendices of the document rather than the Introduction.
The Overall Description gives a general overview of the product and its
requirements, without stating specific requirements. The product perspective ties
the product that is being specified in the SRS to other products in the system, if
there are any. This may include interfaces (user interfaces, hardware or software
interfaces, and communication standards and interfaces). If you have any
requirements particular to a specific installation or mode, that would be described
in a subsection here. A high level overview of the main functionality is provided,
either by inclusion or by referencing a higher level specification and may include
graphical notations that show the logical relationships between elements of the
system. User characteristics (actors, personas, etc.) are described. Finally,
constraints (regulations, limitations, reliability, safety) and assumptions are
documented.
The last section is the Specific Requirements that are to be included in the design
and implementation of the product. This includes a listing of all inputs and
outputs, functions, and non-functional requirements, data storage requirements.
Any supporting information may be put into an appendix.
The IEEE Standard defines a few different methods of organizing the specific
requirements - grouping them by mode of operation or state of the system, by
user class, by object, by feature, by stimulus or input action, or a combination of
them. You can even develop your own method for organizing the specific
requirements of the product.

Refer to Sample Software Requirements Specification Report or SRS Sample or SRS Contents
3.5. Produce Functional and Nonfunctional Software
Requirements
The Functional Requirements Specification documents the operations and activities that a
system must be able to perform.
Functional Requirements should include:
 Descriptions of data to be entered into the system
 Descriptions of operations performed by each screen
 Descriptions of work-flows performed by the system
 Descriptions of system reports or other outputs
 Who can enter the data into the system
 How the system meets applicable regulatory requirements
The Functional Requirements Specification is designed to be read by a general audience.
Readers should understand the system, but no particular technical knowledge should be
required to understand the document.
Examples of Functional Requirements
Functional requirements should include functions performed by specific screens, outlines of
work-flows performed by the system, and other business or compliance requirements the
system must meet. Download an example functional requirements specification or use
these quick examples below.
1. Interface requirements
 Field 1 accepts numeric data entry.
 Field 2 only accepts dates before the current date.
 Screen 1 can print on-screen data to the printer.
2. Business Requirements
 Data must be entered before a request can be approved.
 Clicking the Approve button moves the request to the Approval Workflow.
 All personnel using the system will be trained according to internal SOP AA-
101.
3. Regulatory/Compliance Requirements
 The database will have a functional audit trail.
 The system will limit access to authorized users.
 The spreadsheet can secure data with electronic signatures.
4. Security Requirements
 Members of the Data Entry group can enter requests but can not approve or
delete requests.
 Members of the Managers group can enter or approve a request but can not
delete requests.
 Members of the Administrators group cannot enter or approve requests but
can delete requests.
Depending on the system being described, different categories of requirements are
appropriate. System Owners, Key End-Users, Developers, Engineers, and Quality Assurance
should all participate in the requirement gathering process, as appropriate to the system.
Requirements outlined in the Functional Requirements Specification are usually tested in the
Operational Qualification.
Non-functional requirements
1. Product requirements – Requirements which specify that the delivered product
must behave in a particular way, e.g. execution speed, reliability etc.
2. Organisational requirements – Requirements which are a consequence of
organisational policies and procedures, e.g. process standards used, implementation
requirements etc.
3. External requirements – Requirements which arise from factors which are external
to the system and its development process, e.g. interoperability requirements,
legislative requirements

Refer to Sample Software Requirements Specification Report or SRS Sample or SRS Contents
3.6. Produce Software Architectures from the Requirements

3.6.1. Use of Data Abstraction and Information Hiding

Abstraction and Data hiding are the crucial concepts of the object-oriented programming.
Abstraction is a method of expressing the important properties without involving the
background details.
Data hiding insulates the data from the straight access by other programs.
Abstraction provides a way to create user-defined data types for designing real-world
objects having same properties. Data hiding protects the data and function from the
unauthorized access.
Comparison Chart

Comparison Basis Abstraction Data Hiding

Basic Extracts only relevant information Hides the data from the parts
and ignore inessential details. of the program.
Purpose To hide the complexity. To achieve encapsulation.
Class Class uses the abstraction to derive a Data hiding is used in a class
new user-defined data type. to make its data private.
Focuses on Observable behaviour of the data. Restricting or allowing the
use of data within a capsule.

In simple words, data hiding is an object-oriented programming technique of hiding internal

object details i.e. data members. Data hiding guarantees restricted data access to class
members and maintain object integrity.

In this section, we will understand how data hiding works in C++:

 Encapsulation
 Abstraction
 Data Hiding
Encapsulation, abstraction, and data hiding are closely related to each other. When we talk
about any C++ program, it consists of two fundamental elements:

 Program statements – Part of the program (functions) that performs actions.

 Program data – Data in the program which is manipulated using functions.

The table on the next page illustrates the distinguishing features of Encapsulation,
Abstraction, and Data Hiding in C++.
 Comparison table – Encapsulation, Abstraction and Data Hiding
Encapsulation Data Abstraction Data Hiding in C++

Encapsulation binds the data & functions Data Abstraction is a mechanism of hiding the Data hiding is a process of combining data and functions into a single unit.
together which keeps both safe from implementation from the user & exposing the The ideology behind data hiding is to conceal data within a class, to
prevent its direct access from outside the class. It helps programmers to
outside interference. Data encapsulation interface.
create classes with unique data sets and functions, avoiding unnecessary
led to data hiding. penetration from other program classes.
Example:
Let’s look at an example of encapsulation. Discussing data hiding & data encapsulation, data hiding only hides class
Here, we are specifying the getter & setter #include <iostream> data components, whereas data encapsulation hides class data parts and
1 private methods.
function to get & set the value of using namespace std;
2 Now you also need to know access specifier for understanding data hiding.
variable num without accessing it directly.
3 private, public & protected are three types of protection/ access specifiers
Example: class Abstraction available within a class. Usually, the data within a class is private & the
4 functions are public. The data is hidden, so that it will be safe from
{ accidental manipulation.
#include<iostream> 5
1 private:
using namespace std;  Private members/methods can only be accessed by methods defined
2 6 int num1, num2; as part of the class. Data is most often defined as private to prevent
7 direct outside access from other classes. Private members can be
3 accessed by members of the class.
class Encapsulation
4 8 public:  Public members/methods can be accessed from anywhere in the
{ program. Class methods are usually public which is used to manipulate
5 9
private: the data present in the class. As a general rule, data should not be
6 10 void set(int a, int declared public. Public members can be accessed by members and
// data hidden from objects of the class.
7 outside world 11 b)  Protected member/methods are private within a class and are
8 int num; 12 { available for private access in the derived class.

13 num1 = a; Now let’s look at a data hiding example.

9
14 num2 = b; Example: Data Hiding in C++
10 public:
}
11 // function to 15 1 #include<iostream>
set value of 16
12 2 using namespace std;
// variable x void display()
13 17
void set(int a) { 3 class Base{
14 18
{ cout<<"num1 = " 4
15 19 <<num1 << endl;
num =a;
16 20 cout<<"num2 = " << 5 int num; //by default private
}
17 21 num2 << endl; public:
6
22 }
18
// function to 7
19 return value of 23 };
24 8 void read();
20 // variable x
21 int get() 25 int main() 9 void print();
{ {
22 26
Abstraction obj; 10
23 return num; 27
} obj.set(50, 100); 11};
24 28
}; obj.display();
25 29 12
return 0;
26 30
} 13void Base :: read(){
// main function
27 cout<<"Enter any Integer
int main() 14
value"<<endl; cin>>num;
28
{ 15
29
Encapsulation obj;
30 16}
31 17
obj.set(5);
32
18void Base :: print(){
33
cout<<obj.get(); 19
34 cout<<"The value is "<<num<<endl;
return 0;
35 20}
}
21

22int main(){

23 Base obj;
24

25 obj.read();

26 obj.print();

27

28 return 0;

29}

Output: 5 Output: num1 = 50; num2 = 100 Output: Enter any Integer value
10
The value is 10
3.6.2. Regrouping Requirements

In order to better understand and manage the large number of requirements, it is important
to organize them in logical clusters
 It is possible to classify the requirements by the following categories (or any other
clustering that appears to be convenient)
o Features
o Use cases
o Mode of operation
o User class
o Responsible subsystem
 This makes it easier to understand the intended capabilities of the product
 And more effective to manage and prioritize large groups rather than single
requirements
For classification by Feature is [a set of logically related (functional) requirements that
provides a capability to the user and enables the satisfaction of a business objective]
 The description of a feature should include
o Name of feature (e.g. Spell check)
o Description and Priority
o Stimulus/response sequences
o List of associated functional requirements

3.6.3. Reuse of Requirements

In more recent years the notion of reusing specifications including requirements has started
to get traction. The reuse is particularly important where organizations create a family of
products with similar features or where there is a community of users within an industry or
domain. Other types of requirements such as security and regulatory requirements will
typically apply to a number of projects. Business Rules and Stakeholders Concerns will also
typically apply across many projects and are best catalogued outside individual projects
structures. Enterprise Architect provides a number of sophisticated mechanisms for
managing the reuse of elements across projects including structuring the repository for
reuse, importing requirements from other sources and a Reusable Asset Service.
Requirements reusability consists of reusing requirements and all that comes with it,
including requirements, tests, and use cases derived from the original ones, and all the
traceability between them; attributes and hierarchy. The following procedure can be used to
create a formalised Reuse of Requirements Repository.
1. Create a Standard for Authoring Requirements
Creating a standardized language set for documenting requirements is imperative to
not only the success of your project but also to ensure future requirements projects
follow a similar format. This will help maintain a level of similarity between
requirements, preventing discrepancy when reviewing. The following rules of thumb
can be followed to ensure a standardized language set for requirements writing:
 Create an authoring standard, which includes using a proper syntax for both
functional and non-functional requirements
 Create a standard for documenting business models and business rules
 Create a custom template of relevant attributes, including data definitions,
standards, rationale, design elements, etc
 Use standard units, terms, and definitions to maintain consistency
  Use standard templates for documenting user personas, roles and privileges,
etc
 Avoid ambiguity and vagueness to ensure clarity and quality
Much of this can be automated using requirements analysis tools
2. Write Good Requirements
Nothing beats this. Authoring clear and concise requirements ensures that
engineering teams reap the maximum benefits from requirements reusability. Good
requirements have no ambiguities and are supplemented by rationale, data
definitions, and acceptance criteria. Every requirement should have a unique
identifier and a flag for marking its priority. It is important to use a predetermined
level of detail in a requirement, adding product specific details or details about
implementation can add confusion if the requirement gets reused for another
project without reconsidering contextual information.
3. Be Mindful of Intellectual Property Rights
Reusing requirements can cause Intellectual Property rights violations if you are
reusing something that is not yours by law or available free for public use. When
creating a process, ensure that requirements that came from your users aren’t part
of your repository of reusable requirements.
4. Carefully Select What to Reuse
Not all requirements are fit to be reused. When choosing which requirements to
reuse, consider if they may change over time, or if they are standardized to be
relevant to a number of projects. Here are a few examples of requirements
document categories that may be eligible for reuse:
 Non-functional requirements (performance criteria, page load time, etc.)
 Functional Requirements
 User classes and personas
 Business models and rules
 Security requirements
 Compliance and standards (safety requirements, building codes, etc.)
 Glossary and data definitions
 Accessibility requirements (web content accessibility guidelines, etc.)
 Symmetrical user functions (create, read, update, delete and search, etc.)
 Core functions (signup, sign in and recover password, device reset, etc.)
 Document templates (requirement specifications, design documents, etc.)
 Information sources on domain knowledge
Requirements engineers can create reuse patterns to ensure that only relevant and
useful requirements are being copied or linked to newly conceived project ideas.
5. Maintain the Repository
Once you have a categorized set of reusable requirements, the next step is
maintenance. Regardless of the requirements style or context, the repository should
be kept up-to-date at all times. This is done to reduce the risk of reusing obsolete
information and to take note of all changes being made. Make sure to update
requirements as new information or data is available, this ensures reusable
requirements longevity.
 6. Do a Reusability Retrospective
Another best practice is to host retrospective meetings periodically to ensure that
the requirements reusability process is up to date. Collecting feedback and lessons
learned should be part of the process, with a way to track which pointers are being
implemented to improve the process. Do this often to keep track of problems and
work on solutions collaboratively. Keep a backlog of ideas / changes to be tested /
implemented in the process and review in every retrospective meeting; this will
reset the sail towards an exponentially improved requirements reusability process.

3.6.4. Requirements Reusability modes

1. COPY AND PASTE: There are several ways of reusing requirements, and copy and
paste is the most widely used technique. Even though very basic, it may be a good
starting point. There are multiple variants of this method, such as copying and
pasting in read-only mode.
2. COPY AND LINK: An advanced evolution of the copy and paste is to be able to keep a
reference from the pasted requirement to the original one. This is a much more
powerful option, as it will allow us to create a branch (a diverging version with the
same unique identifier) from the original requirement, but still receive updates if the
original requirement is modified. This will allow us to keep working on our own
branch, or merge to the original one at any point in time. This is a extremely efficient
way of performing a change and populating it to all the ongoing projects in the
company, and specially useful to deal with product variants and branches.
3. LINK: This mode allows to display a representation of a set of requirements from
another project in read-only mode. Any changes made to the original requirements
are automatically populated to the rest of the projects reusing them. This mode is
specially useful when dealing with standards and norms, in which projects need not
to modify them, but need to make sure they keep up to date.
4. SHARE: This mode allows projects to share the ownership of a set of requirements,
being requirements editable and automatically available to all the projects at the
same time.
Requirements Engineering is time-intensive, and much of a project’s success depends on
getting it right. Reusing requirements is a way to save time and to ensure the quality of
requirements as they have been written, implemented and tested before. If done hastily or
without care, reusing requirements can cause waste, so project engineers must streamline
the process by following its best practices and creating a culture that values smart work and
reuse of available resources and knowledge.
3.6.5. Automation of the Requirements

What to look for when choosing a Requirements Management Tool:

1. Support for different software development methodologies: There are many
processes for developing software, thus, it’s important for a requirements
management tool to be flexible and accommodate a variety of software
development methodologies. Even if you do follow a certain methodology, you
might have your own flavour of it. A requirements management tool that supports a
variety of different software development methodologies can adapt and change as
your team does the same.
2. Requirements Management: This includes the ability to define requirements, model
relationships between them, reuse requirements, and export/import requirements
data for creating requirements documentation.
3. Hierarchical organization
Some requirements need to be broken out into smaller sub-items. In agile, this is
called an “epic”. An epic effectively contains many different feature requests, tasks,
or business & technical requirements. It is a chunk of work. A requirements
management tool shouldn’t pigeon-hole you into categorizing everything the same
exact way, on the same level. Make sure you’re able to organize your requirements
using a hierarchy that works for you and your team.
4. Requirements Visualization: This includes graphical tools and reports, interactive
flows and simulations, dashboards, storyboards, and functionality for graphical
models like UML or SysML models. In addition, a good requirements management
tool has to have some form of visual modelling. This helps users both gain a clearer
understanding of processes and rules and communicate these to other stakeholders.
5. Traceability and Real-Time Impact Analysis: Ultimately, being able to establish
automatic relationships across requirements is key in requirements management.
This is one of the major advantages of using requirements management software
over a simple spreadsheet. Traceable requirements and impact analysis include the
ability to run test cases. In effect, this allows you to mitigate risks when
requirements, people, decisions, and timelines inevitably shift during the course of a
project.
6. Collaboration: A good requirements software should include functionality for
interaction between users. This includes the ability to review, approve, provide
electronic signatures, gather input, and receive notification of other users’ activity
within the software.
7. Integrations with Other Tools: The basic integrations you should look for are
integrations with software development tools (SW development tools) word
document, and spreadsheet tools. All tools should provide easy export / import of
data to Excel as well as export of reports and software requirements documents to
Word. Additionally, many requirements management tools come with a pre-built
two-way sync with Jira.
8. Security and permissions: Some requirements might contain classified information.
A requirements tool should take security seriously. Do your homework and see how
the company positions themselves as it pertains to security practices. Some projects
are private, and some information needs to be accessed only by certain roles.
Permissions or role based access control allows you to have your entire team in the
tool without worry they have access to too much.
 Requirements Management tools sample list include:
Tool Features
Modern The software reduces time to value delivery by providing users with end to end traceability, ingenious process automation, online document authoring, visualization support.
Requirements
Features:

 AI inspired BA Assistant- Alice

 Customizable document generation
 Three visualization types: Diagrams, Mock-ups, Use Cases
 Online review and approval
 Baselining, Requirements reuse and Impact assessment
 Test Case Automation and User Story generation
 Online document authoring in pre-defined templates- Smart Docs
 Planning boards and Customizable dashboards and Supports BABOK, BABOK Agile, Scrum and Hybrid taxonomies
Jama Software Jama Software provides the leading platform for requirements, risk, and test management. With Jama Connect and industry-focused services, teams building complex products,
systems, and software improve cycle times, increase quality, reduce rework, and minimize effort proving compliance.
Features:

 Accurately capture and communicate requirements, goals, progress, and interdependencies throughout the development process
 End-to-end live traceability of people, data, and processes
 Real-time impact analysis showing the effect of changes related to upstream and downstream requirements
 Integrate with ALM, PLM, QA, MBSE
 Define, organize, and execute requirements-based test plans and test cases and Reuse validated requirements to quickly replicate features across products
Rational Doors: Rational DOORS is a requirements management application. It is a useful tool for optimizing, collaborating, and verifying requirements across the organization. This RM tool
allows to capture, trace, analyze and manage changes to information.
Features:

 Requirements management is performed from the centralized location for better team collaboration
 It provides tractability by linking requirements to design items, test plans, test cases, etc.
 It offers scalability to address changing requirements management needs
 Test tracking toolkit for manual test environments to link requirements to test cases
 It helps users to manage changes to requirements either with pre-defined change proposal system or a more customizable change control workflow
Download link: https://www.ibm.com/developerworks/downloads/r/ordng/index.html
Tool Features
Visure Visure Solutions, Inc. is a trusted specialized requirement ALM partner for companies of all sizes across safety-critical and business-critical industries.
Features:

 Support of various development processes, Agile, V-model, Waterfall

 Round-Trip integration with MS Word/Excel
 Collaborative role-based sign-off for Review & Approval process
 Full traceability from system requirements all the way down to testing
 Risk Management, Test Management, Bug Tracking
 Requirements quality checker using Natural Language Processing and semantic analysis
 Customizable standards compliance templates for ISO26262, IEC62304, IEC61508, CENELEC50128, DO178/C, FMEA, SPICE, CMMI, etc.
 Open environment integrated with several tools such as DOORS, Jama, Siemens Polarion, PTC, Perforce, JIRA, Enterprise Architect, HP ALM, Microfocus ALM, PTC,
TFS, Word, Excel, Test RT, RTRT, VectorCAST, LDRA and other tools
IRIS Business It allows business owners to plan, deliver, and implement their corporation's strategies. It also provides rich design, modeling, and management functionality to track changes
Architect: instantly. It contributes to cut risk and enhance the decision-making process.
Features:

 It is easy to use and user-friendly tool

 It allows easy Collaboration
 It supports Cloud, Saas, Mac, Windows, and Web
 Easy option for history tracking
 Offers complete status Reporting
 Provides complete summary Reports
 Easy option for traceability and User Defined Attributes
Download link: https://biz-architect.com/request-free-trial/
3.7. Contrast System Modeling Perspectives of Context,
Interaction, Structure, and Behavior using the Unified
Modeling Language (UML)
Models are used during the requirements engineering process to help derive the
requirements for a system, during the design process to describe the system to engineers
implementing the system and after implementation to document the system’s structure and
operation. You may develop models of both the existing system and the system to be
developed:

1. Models of the existing system are used during requirements engineering. They help
clarify what the existing system does and can be used as a basis for discussing its
strengths and weaknesses. These then lead to requirements for the new system.
2. Models of the new system are used during requirements engineering to help explain
the proposed requirements to other system stakeholders. Engineers use these
models to discuss design proposals and to document the system for
implementation. In a model-driven engineering process, it is possible to generate a
complete or partial system implementation from the system model.

The most important aspect of a system model is that it leaves out detail. A model is an
abstraction of the system being studied rather than an alternative representation of that
system. Ideally, a representation of a system should maintain all the information about the
entity being represented but unfortunately, the real world (also knows as the universe of
discourse) is utterly complex so weed to simplify. An abstraction consciously simplifies and
picks out the most evident characteristics.
You may develop different models to represent the system from different perspectives
[SOMMERVILLE2010]. For example:

1. An external perspective, where you model the context or environment of the

system.
2. An interaction perspective where you model the interactions between a system and
its environment or between the components of a system.
3. A structural perspective, where you model the organization of a system or the
structure of the data that is processed by the system.
4. A behavioral perspective, where you model the dynamic behaviour of the system
and how it responds to events.
3.7.1. Context Model

Context model of the online store

Once some decisions on the boundaries of the system have been made, part of the
analysis activity is the definition of that context and the dependencies that a system has
on its environment. Normally, producing a simple architectural model is the first step in
this activity.

Context models normally show that the system's environment contains other systems but
the types of relationships between the systems of the environment and the system that is
being specified are not shown. That is why it is common to create some models describing
business processes showing what activities humans or automated processes will execute.
UML provides activity diagrams in order to describe those high-level use processes.

It is easy to figure out where the boundaries of this system are. We can tell which
functionalities belong to the system and which are those that are external to it.
3.7.2. Interaction Model

All systems involve interaction of some kind. This can be user interaction, which involves
user inputs and outputs, interaction between the system being developed, and other
systems or interaction between the components of the system.
 Modelling user interaction is important as it helps to identify user requirements.
 Modelling system to system interaction highlights the communication problems
that may arise.
 Modelling component interaction helps us understand if a proposed system
structure is likely to deliver the required system performance and dependability.
Sommerville covers two related (complementary) approaches to interaction modelling:
1. Use case modelling, which is mostly used to model interactions between a system
and external actors (users or other systems).
2. Sequence diagrams, which are used to model interactions between system
components, although external agents may also be included.
Use case models and sequence diagrams present interaction at different levels of detail
and so may be used together. The details of the interactions involved in a high-level use
case may be documented in a sequence diagram.
Each use case represents a discrete task that involves external interaction with a system.
Actors in a use case may be people or other systems. Use cases can be represented using a
UML use case diagram and in a more detailed textual/tabular format.
Simple use case diagram:

Use case description in a tabular format:

Use case title Transfer data

A receptionist may transfer data from the MHC-PMS to a general patient record database
that is maintained by a health authority. The information transferred may either be updated
Description
personal information (address, phone number, etc.) or a summary of the patient's diagnosis
and treatment.

Actor(s) Medical receptionist, patient records system (PRS)

Patient data has been collected (personal information, treatment summary);
Preconditions The receptionist must have appropriate security permissions to access the patient
information and the PRS.
Post conditions PRS has been updated
1. Receptionist selects the "Transfer data" option from the menu.
Main success 2. PRS verifies the security credentials of the receptionist.
scenario 3. Data is transferred.
4. PRS has been updated.
2a. The receptionist does not have the necessary security credentials.
Extensions 2a.1. An error message is displayed.
2a.2. The receptionist backs out of the use case.
UML sequence diagrams are used to model the interactions between the actors and the
objects within a system. A sequence diagram shows the sequence of interactions that take
place during a particular use case or use case instance. The objects and actors involved are
listed along the top of the diagram, with a dotted line drawn vertically from these.
Interactions between objects are indicated by annotated arrows.
3.7.3. Structural Model

Structural model represents the framework for the system and this framework is the place
where all other components exist. Structural modelling captures the static features of a
system. They consist of the following:

 Classes diagrams
 Objects diagrams
 Deployment diagrams
 Package diagrams
 Composite structure diagram
 Component diagram
Structural models of software display the organization of a system in terms of the
components that make up that system and their relationships. Structural models may
be static models, which show the structure of the system design, or dynamic models, which
show the organization of the system when it is executing. You create structural models of a
system when you are discussing and designing the system architecture.
UML class diagrams are used when developing an object-oriented system model to show
the classes in a system and the associations between these classes. An object class can be
thought of as a general definition of one kind of system object. An association is a link
between classes that indicates that there is some relationship between these classes. When
you are developing models during the early stages of the software engineering process,
objects represent something in the real world, such as a patient, a prescription, doctor, etc.
Generalization is an everyday technique that we use to manage complexity. In modelling
systems, it is often useful to examine the classes in a system to see if there is scope for
generalization. In object-oriented languages, such as Java, generalization is implemented
using the class inheritance mechanisms built into the language. In a generalization, the
attributes and operations associated with higher-level classes are also associated with the
lower-level classes. The lower-level classes are subclasses inherit the attributes and
operations from their superclasses. These lower-level classes then add more specific
attributes and operations.

An aggregation model shows how classes that are collections are composed of other classes.
Aggregation models are similar to the part-of relationship in semantic data models.
3.7.4. Behavioural Modelling

Behavioural models are models of the dynamic behaviour of a system as it is executing.

They show what happens or what is supposed to happen when a system responds to a
stimulus from its environment. Two types of stimuli:
 Some data arrives that has to be processed by the system.
 Some event happens that triggers system processing. Events may have associated
data, although this is not always the case.
Many business systems are data-processing systems that are primarily driven by data. They
are controlled by the data input to the system, with relatively little external event
processing. Data-driven models show the sequence of actions involved in processing input
data and generating an associated output. They are particularly useful during the analysis of
requirements as they can be used to show end-to-end processing in a system. Data-driven
models can be created using UML activity diagrams:

Data-driven models can also be created using UML sequence diagrams:

Real-time systems are often event-driven, with minimal data processing. For example, a
landline phone switching system responds to events such as 'receiver off hook' by
generating a dial tone. Event-driven models shows how a system responds to external and
internal events. It is based on the assumption that a system has a finite number of states
and that events (stimuli) may cause a transition from one state to another. Event-driven
models can be created using UML state diagrams:
3.8. Chapter 3: Questions
1. Differentiate:
a. User requirements from system requirements. [4]
b. Functional from Non-functional requirements. [4]
c. Core Requirements and Ancillary requirements. [4]
2. Describe four (4) challenges that can be faced in the determination of requirements
for a new information system. [12]
3. Compare document analysis and prototyping as ways of eliciting for requirements. [10]
4. Explain the meaning of Requirements Traceability. [3]
5. Using examples differentiate Implicit Requirements Traceability from Explicit
Requirements Traceability. [6]
6. Explain aspect of "Source traceability information" [2]
7. Explain the following terms:
a. Forward traceability. [2]
b. Bidirectional traceability. [2]
8. Identify and briefly explain three documents that can be used to trace the
correctness of tested code. [9]
9. Explain five reasons for assessing the feasibility of system requirements. [10]
10. Is the Review of a System Requirements Document a necessity? Support your answer. [6]
11. Explain the concept of "system domain constraints". [5]
12. Describe three (3) items included in checklists for the requirements review process. [6]
13. Explain any three (3) possible outcomes of the requirements validation process. [6]
14. Explain the purposes of:
a. Design Validation [5]
b. System Validation [5]
c. Process Validation [5]
d. Document Validation [5]
15. Discuss the significance of the following in the validation procedures:
a. Qualified personnel [2]
b. Validation tools [2]
c. Measuring equipment [2]
d. Facilities [2]
e. Validation procedures [2]
16. Explain the purpose and contents of the following sections of the Requirements
Specification Document:
a. Introduction [4]
b. External Interface requirements [4]
c. System features [4]
17. Describe one specific requirement that can be found under the following broad
functional requirements:
a. Business Requirements. [3]
b. Regulatory/Compliance Requirements. [3]
c. Security Requirements. [3]
18. Explain two issues covered under each category of non-functional requirements listed
below:
a. Product requirements. [4]
b. Organisational requirements. [4]
c. External requirements. [4]
19. Explain the following types of Information / Data Hiding using C++:
a. Private members/methods [4]
b. Public members/methods [4]
c. Protected member/ methods [4]
20. Explain the concept of Data Abstraction. [5]
21. What do the following Requirements Reusability modes entail?
a. COPY AND PASTE [4]
b. COPY AND LINK [4]
c. LINK [4]
d. SHARE [4]
22. Explain any three aspects to consider when choosing a requirements management tool. [9]
23. List three (3) tasks of requirements management process that can be automated? [3]
24. Explain the following models:
a. Context model. [4]
b. Interaction model. [4]

For further reading refer to Software Engineering – Ian Sommerville, UML

Classroom , and SEBok_v2.1_Part7