LAB MANUAL

SOFTWARE REQUIREMENTS
ENGINEERING

DEPARTMENT OF SOFTWARE ENGINEERING

FACULTY OF ENGINEERING & COMPUTING
NATIONAL UNIVERSITY OF MODERN LANGUAGES
ISLAMABAD
Contents

Preface.................................................................................................................. 5
Lab #1: Understand the Importance of Requirements Engineering in Software Development 6
Objective............................................................................................................ 6
Theoretical Description......................................................................................... 6
Importance of RE:............................................................................................ 6
Embedding RE into Process Models.................................................................8
Lab Task:............................................................................................................ 9
Lab #2: System and Context Diagram.................................................................10
Objective.......................................................................................................... 10
Theoretical Description....................................................................................... 10
Defining the System Boundary.......................................................................10
Defining the Context Boundary.......................................................................10
Example 1: LinkedIn application.....................................................................10
Example 2: A grocery Store “Fresh Mart”......................................................................11
Lab Task:.......................................................................................................... 13
Lab #3: Identify Requirements Sources and Apply Kano Model.............................16
Objective.......................................................................................................... 16
Theoretical Description....................................................................................... 16
Requirement Sources..................................................................................... 16
Missing Stakeholders..................................................................................... 16
Handling Stakeholders................................................................................... 16
Kano Model.................................................................................................... 18
Lab Task:.......................................................................................................... 19
Lab #4: Requirements Elicitation Techniques.......................................................20
Objective.......................................................................................................... 20
Theoretical Description....................................................................................... 20
Requirement Elicitation Techniques................................................................20
Lab Task:.......................................................................................................... 26
Lab #5: Requirements Elicitation Techniques.......................................................27
Objective.......................................................................................................... 27
Theoretical Description....................................................................................... 27
Document-centric Techniques.......................................................................27
 Observation Techniques................................................................................. 27
Lab Tasks.......................................................................................................... 28
Lab #6: Documenting Requirements in Natural Language....................................30
Objective.......................................................................................................... 30
Theoretical Description....................................................................................... 30
Lab Task........................................................................................................... 33
Lab #7: Requirements Construction using Template...........................................34
Objective.......................................................................................................... 34
Theoretical Description....................................................................................... 34
Effects of Documenting Requirements in Natural Language...........................34
Requirements Construction using Template..................................................35
Lab Task:.......................................................................................................... 38
Lab #8: Model-based Requirements Documentation...........................................39
Objective.......................................................................................................... 39
Theoretical Description....................................................................................... 39
Model:............................................................................................................ 39
UML............................................................................................................... 39
Lab Task:.......................................................................................................... 49
Lab #10: Requirements Validation and Negotiation..............................................50
Objective.......................................................................................................... 50
Theoretical Description....................................................................................... 50
Requirements Validation and Negotiation.......................................................50
Lab Task:.......................................................................................................... 58
Lab#11: Requirements Management and Prioritizing Requirements.....................61
Objective.......................................................................................................... 61
Theoretical Description....................................................................................... 61
Attribute Scheme............................................................................................ 61
Requirements Prioritization............................................................................ 66
Lab Tasks.......................................................................................................... 68
Lab#12 Traceability of requirements.....................................................................69
Objective.......................................................................................................... 69
Theoretical Description....................................................................................... 69
Lab #13: Requirement configuration and change management........................72
Objective.......................................................................................................... 72
Theoretical description....................................................................................... 72
Lab tasks.......................................................................................................... 74
Preface
This lab manual has been meticulously crafted to support the students of Software Engineering in
comprehensively studying and implementing the principles of Software Requirements Engineering.
This manual will guide students through the process of understanding, gathering, specifying,
validating, and managing software requirements with precision and effectiveness. They will gain
practical experience in identifying stakeholders' needs, creating requirement specifications, and
employing industry-standard techniques and tools to ensure the success of software projects. After the
completion of this course, students will possess the skills to adeptly navigate the complex terrain of
software requirements, equipping them to excel in real-world software development endeavours.
Lab #1: Understand the Importance of Requirements
Engineering in Software Development
Objective
The objective of this lab is to familiarize students with the importance of Requirements
Engineering (RE) in software development and its impact on project success.
Theoretical Description
In this lab task, students will analyze real-world examples of software projects to identify the
role of Requirements Engineering in ensuring project success. They will examine case studies
and reflect on how well-defined requirements contribute to the overall effectiveness of
software development efforts.
Importance of RE:
Early detection of defects is crucial in software development as their cost increases
exponentially throughout the project lifecycle. Effective Requirements Engineering (RE)
practices mitigate this risk by ensuring accurate stakeholder needs assessment, significantly
enhancing project success rates. Clear and validated requirements not only boost customer
satisfaction but also minimize rework and schedule delays, fostering efficient development
cycles and timely deliveries.
Case Studies
1. Patriot Missile System Failure
During the Gulf War in 1991, a Patriot missile battery in Dhahran, Saudi Arabia, failed to
intercept an incoming Scud missile launched by Iraq. The failure resulted in the deaths of 28
U.S. soldiers and numerous injuries. The cause was later traced back to a software defect
related to requirements engineering.
The Patriot missile system used a time-based guidance system to track and intercept
incoming missiles. However, due to the system's design, a small timing error accumulated
over time, resulting in inaccurate tracking and targeting of the incoming Scud missile.
Inadequate Precision Requirement: The software controlling the Patriot missile system did
not meet the required precision for tracking fast-moving targets like the Scud missile. The
system's design did not adequately account for the accumulation of timing errors, leading to a
failure to intercept the incoming threat.
2. Denver International Airport Baggage Handling System
The baggage handling system at Denver International Airport (DIA) faced significant issues
during its initial rollout in 1995. Poorly defined requirements and insufficient testing led to
baggage being misrouted, delayed, or lost. The project experienced numerous delays and cost
overruns, with the final price tag exceeding $2 billion.
The Denver International Airport Baggage Handling System project underscored the
significance of well-defined requirements in project success. Inadequate requirements
definition resulted in operational inefficiencies, delays, and cost overruns.
Improving the requirements engineering process could have involved conducting a
comprehensive stakeholder analysis, engaging in extensive requirements elicitation activities,
and employing effective requirements documentation techniques such as use cases and user
stories.
3. Amazon Prime
Amazon Prime is a subscription service that offers various benefits to its members, including
free two-day shipping, streaming of movies and TV shows, and access to exclusive deals.
Amazon's success in delivering a seamless user experience and meeting customer
expectations can be attributed to its effective requirements engineering practices, which
prioritize customer needs and preferences.
Amazon Prime's success can be attributed to its effective requirements engineering practices,
which prioritize customer needs and preferences. By understanding customer expectations
and translating them into actionable requirements, Amazon has created a service that
consistently delights its customers.
Other companies can replicate Amazon's success by investing in customer research, actively
soliciting feedback, and iteratively refining their products based on customer input.
Additionally, employing agile development methodologies can enable rapid adaptation to
changing customer needs.
4. Airbus A380
The development of the Airbus A380, the world's largest passenger airliner, faced numerous
challenges, including delays and cost overruns. However, the A380 program also exemplifies
the benefits of rigorous requirements engineering practices in mitigating risks and
minimizing rework. Airbus invested heavily in requirements management tools and
processes to ensure that the aircraft met regulatory standards and customer expectations.
Airbus leveraged requirements engineering to minimize rework and schedule delays during
the development of the Airbus A380 by implementing robust requirements management
processes, including version control, traceability, and change management.
Best practices in requirements management include conducting regular reviews and
inspections, maintaining clear documentation, and fostering collaboration between
development teams and stakeholders. By following these practices, organizations can
proactively identify and address requirements issues before they escalate into costly delays.
5. The Mars Climate Orbiter
In 1999, NASA's Mars Climate Orbiter mission ended in failure when the spacecraft entered
Mars' atmosphere at too low an altitude and disintegrated. The cause was traced back to a
discrepancy between imperial and metric units used in the software. The cost of the mission
was approximately $327.6 million. Read more at: https://www.washingtonpost.com/wp-
srv/national/longterm/space/stories/orbiter100199.htm and
https://www.simscale.com/blog/nasa-mars-climate-orbiter-metric/
6. Ariane 5 Flight 501
On June 4, 1996, the maiden flight of the Ariane 5 rocket, Flight 501, ended in catastrophic
failure just 40 seconds after liftoff. The rocket veered off course and self-destructed due to a
software defect related to requirements engineering. The guidance system of the Ariane 5
rocket used 64-bit floating-point numbers to represent horizontal velocity, a value that
exceeded the limit of what could be represented by a 16-bit signed integer. During flight, a
conversion of this value from a 64-bit floating-point to a 16-bit signed integer caused an
overflow error, leading to erroneous flight data. The lack of proper error handling
mechanisms to detect and recover from the overflow condition resulted in the generation
of incorrect commands being sent to the rocket's engines, causing it to deviate from its
intended trajectory and self-destruct. https://www.youtube.com/watch?
v=gp_D8r-2hwk https://medium.com/dataseries/crash-and-burn-a-short-story-of-ariane-5-
flight-501- 3a3c50e0e284
7. Therac-25 radiation therapy machine
The Therac-25 radiation therapy machine, used for cancer treatment, experienced multiple
incidents between 1985 and 1987 where patients received massive radiation overdoses due to
software defects related to requirements engineering. Incomplete safety requirements and
ambiguous user interface specifications contributed to operator errors and system
malfunctions. The lack of proper testing and validation procedures allowed latent defects to
remain undetected, resulting in severe injuries and fatalities. Following the incidents,
extensive rework was required to address the software defects and improve the safety features
of the Therac-25 system. This case underscores the critical importance of robust requirements
engineering practices in the development of safety-critical medical devices.
https://corgicorporation.medium.com/software-engineer-failures-therac-25-d67864d96cc2
Embedding RE into Process Models

1
Figure 1: Embedding RE into process Models

Example Project: Autonomous Delivery Robot for Urban Environments (ADRU)

Description: The Autonomous Delivery Robot for Urban Environments (ADRU) is a
sophisticated robotic system designed to autonomously navigate urban environments and
deliver packages to specified destinations. The robot utilizes advanced sensors, machine
learning algorithms, and communication technologies to navigate complex urban landscapes,
avoid obstacles, and interact with pedestrians and vehicles safely.

1
Book: Mastering the Requirements Process – Third Edition, Page # 24
Identifying Suitable Process Model:
Selecting the appropriate process model for the ADRU project requires consideration of
factors such as project complexity, uncertainty, stakeholder involvement, and the need for
flexibility. Potential options include Agile, Spiral, or Incremental model.
Agile Methodology: Agile is suitable for the ADRU project due to its iterative and adaptive
approach, allowing for continuous refinement of requirements and incremental development
of software components. Agile promotes collaboration, flexibility, and responsiveness to
changing customer needs, making it well-suited for complex and dynamic projects like
ADRU.
Requirements Engineering in the ADRU Project:
Conducting Requirements Engineering in the ADRU project involves several key steps to
ensure the accurate capture and validation of stakeholder needs:
Requirement Elicitation: Engage with stakeholders, including end-users, urban planners,
delivery companies, and regulatory authorities, to identify and prioritize requirements.
Conduct workshops, interviews, and surveys to gather insights into user preferences, safety
regulations, and operational constraints.
Requirement Analysis: Analyze gathered requirements to identify common themes,
dependencies, and potential conflicts. Use techniques such as use case modeling, scenario
analysis, and risk assessment to understand the scope and impact of requirements on the
ADRU system.
Requirement Specification: Document requirements in a clear and structured manner using
artifacts such as user stories, functional specifications, and system architecture diagrams.
Ensure that requirements are unambiguous, complete, and traceable to stakeholder needs and
project objectives.
Requirement Validation: Validate requirements with stakeholders through reviews,
demonstrations, and prototypes. Use simulation tools and virtual environments to test the
feasibility and performance of the ADRU system under various operating conditions. Seek
feedback to confirm that requirements meet user expectations and address safety and
regulatory requirements effectively.
Requirement Management: Establish a process for managing changes to requirements over
time. Use version control, configuration management, and change control procedures to track
and document changes, ensuring alignment with project goals and stakeholder needs.
By following these steps, students can effectively conduct Requirements Engineering in the
ADRU project, ensuring that stakeholder needs are accurately captured and translated into
system specifications. The chosen Agile methodology allows for flexibility and collaboration,
enabling the ADRU project team to adapt to evolving requirements and deliver a successful
autonomous delivery robot for urban environments.
Lab Task:
Analyze real-world case studies of software projects that experienced communication
challenges leading to requirement misunderstandings or project failures. Identify the
root causes and propose strategies for preventing similar issues in future projects.
Lab #2: System and Context Diagram
Objective
The objective of the lab is to teach students to identify, define, and document system and
context boundaries, using practical exercises to create context diagrams and detailed
documentation for effective system design.
Theoretical Description
Defining the System Boundary
The system boundary separates the system to be developed from its environment, i.e., it
separates the part of the reality that can be modified or altered by the development process
from aspects of the environment that cannot be changed or modified by the development
process.
Defining the Context Boundary
Aspects within the system context can be business processes, technical processes, people and
roles, organizational structures, and components of the IT infrastructure. The system context
consists of other systems, groups of stakeholders that in some way use the interfaces of the
system to be developed, and additional requirements sources and their interrelation.
Example 1: LinkedIn application
LinkedIn Application comprises broader elements surrounding the application, including:

Users and Stakeholders:

 Individual users: Professionals, job seekers, students, freelancers, and individuals
seeking networking opportunities.
 Businesses: Employers, recruiters, companies, organizations, and entrepreneurs
leveraging LinkedIn for talent acquisition, branding, and marketing.
 Educational institutions: Students, alumni, faculty, and staff members using LinkedIn
for networking, recruitment, and professional development.

Networking and Professional Relationships:

 Networking events: Conferences, seminars, workshops, and industry events where
professionals connect and network.
 Professional associations: Industry-specific groups, organizations, and associations
fostering networking and collaboration among professionals.
 Business Processes: Workflows related to user registration, content moderation,
advertising, and revenue generation.

Industry and Market Dynamics:

 Industry trends: Technological advancements, market shifts, regulatory changes, and
emerging opportunities impacting professionals and businesses.
  Competitor landscape: Other professional networking platforms, job portals, and
talent acquisition solutions competing with LinkedIn.

Technological Environment:
 Mobile and web platforms: Devices, operating systems, browsers, and screen sizes
used by LinkedIn users to access the platform.
 Technology infrastructure: Data encryption, authentication mechanisms, data
backups, system maintenance procedures, Networking equipment, cloud services,
third-party APIs, and integrations with external systems

Economic and Social Factors:

 Economic conditions: Job market dynamics, unemployment rates, and economic
trends influencing hiring decisions and professional opportunities.
 Social networks: Connections, relationships, and interactions outside of LinkedIn that
influence users' professional activities and decisions.

Figure 2: System and Context Diagram for LinkedIn Application

Example 2: A grocery Store “Fresh Mart”

A local grocery store aims to modernize its operations and enhance customer satisfaction by
developing a mobile application called "FreshMart." The goal of FreshMart is to provide
customers with convenient access to product information, promotions, and online ordering
for home delivery or in-store pickup. With objectives to improve customer engagement,
increase sales, and optimize operational efficiency, stakeholders including grocery store
owners,
customers, store managers, delivery personnel, and developers collaborate on this project.
The app features a comprehensive product catalogue, search and filter options, online
ordering capabilities, promotions and deals highlights, order tracking functionalities,
customer accounts, and feedback and support channels. However, the development process
must adhere to requirements such as platform compatibility, integration with inventory
management systems, secure payment processing, intuitive user interface, compliance with
regulations, and constraints including budget, time, and resource limitations.
Goal:
The goal of the "FreshMart" mobile application project is to modernize operations and
enhance customer satisfaction for the "Green Valley Mart" grocery store by providing
convenient access to product information, promotions, and online ordering for home delivery
or in-store pickup.
Objective:
To achieve the goal of enhancing customer satisfaction and increasing sales, the objectives of
the "FreshMart" mobile application project include:
 Improve customer engagement and satisfaction through easy access to product
information and promotions.
 Increase sales by providing visibility to promotions and facilitating online ordering for
home delivery or in-store pickup.
 Optimize operational efficiency for store management and order fulfillment by
streamlining order management processes and improving inventory tracking.

Stakeholders:
 Grocery Store Owners: Invest in the development of the mobile app and oversee its
implementation.
 Customers: Use the app to browse products, place orders, and receive updates on
promotions.
 Store Managers: Manage inventory, fulfill orders, and monitor app performance.
 Delivery Personnel: Deliver orders to customers' homes or assist with in-store pickups.
 Developers: Design, develop, and maintain the mobile application.

Features:
 Product Catalogue: Display a comprehensive list of available products with
descriptions, prices, and images.
 Search and Filter: Allow customers to search for specific products and filter results by
category, brand, or price range.
 Online Ordering: Enable customers to place orders, specify delivery preferences, and
select payment options.
  Promotions and Deals: Highlight ongoing promotions, discounts, and special offers to
attract customers.
 Order Tracking: Provide real-time updates on order status, including confirmation,
preparation, and delivery.
 Customer Accounts: Allow customers to create accounts, save preferences, and track
order history.
 Feedback and Support: Collect feedback from customers and provide assistance
through in-app messaging or chat support.

Requirements:
 The app must support both iOS and Android platforms to reach a wide audience.
 It should integrate with the store's existing inventory management system to maintain
accurate product availability.
 Secure payment processing and data encryption are essential to protect customers'
sensitive information.
 The app should have an intuitive user interface and responsive design to ensure a
seamless user experience across devices.
 Integration with third-party delivery services may be required to facilitate home
deliveries.
 Compliance with local regulations and privacy laws governing e-commerce and data
protection.

Constraints:
 Budget constraints may limit the scope of features and functionalities that can be
implemented within the project timeline.
 Time constraints require timely delivery of the app to capitalize on market
opportunities and seasonal demands.
 Limited resources, including development expertise and technology infrastructure,
may impact the project's execution and scalability.
Lab Task:
Task # 1: Consider the scenario and answer the questions provided at the end.
Scenario: Medicine Shop Automation (MSA) software:
A retail medicine shop deals with a large number of medicines procured from various
manufacturers. The shop owner maintains different medicines in wall mounted and numbered
racks.
The shop owner maintains as few inventories for each item as reasonable, to reduce inventory
overheads after being inspired by the just-in-time (JIT) philosophy.
Thus, one important problem the shop owner faces is to be able to order items as soon as the
number of items in the inventory reduces below a threshold value. The shop owner wants to
maintain medicines to be able to sustain selling for about one week. To calculate the
threshold value for each item, the software must be able to calculate the average number of
medicines sales for one week for each part.
At the end of each day, the shop owner would request the computer to generate the items to
be ordered. The computer should print out the medicine description, the quantity required,
and the address of the vendor supplying the medicine. The shop owner should be able to store
the name, address, and the code numbers of the medicines that each vendor deals with.
Whenever new supply arrives, the shop owner would enter the item code number, quantity,
batch number, expiry date, and the vendor number. The software should print out a cheque
favouring the vendor for the items supplied.
When the shop owner procures new medicines it had not dealt with earlier, he should be able
to enter the details of the medicine such as the medicine trade name, generic name, vendors
who can supply this medicine, unit selling and purchasing price. The computer should
generate a code number for this medicine which the shop owner would paste the code number
in the rack where this medicine would be stored. The shop owner should be able to query
about a medicine either using its generic name or the trade name and the software should
display its code number and the quantity present.
At the end of every day the shop owner would give a command to generate the list of
medicines which have expired. It should also prepare a vendor-wise list of the expired items
so that the shop owner can ask the vendor to replace these items. Currently, this activity alone
takes a tremendous amount of labour on the part of the shop owner and is a major motivator
for the automation endeavour.
Whenever any sales occur, the shop owner would enter the code number of each medicine
and the corresponding quantity sold. The MSA should print out the cash receipt.
The computer should also generate the revenue and profit for any given period. It should also
show vendor-wise payments for the period.
Questions:
1. Identify the goal of the system.
2. Identify stakeholders of the proposed system.
3. Identify features of the proposed system.
4. Write the requirements of the proposed system.
5. Draw system and context diagram for the above provided scenario.
Task # 2: Draw system and context model for Weather Forecasting System.
Task # 3: Draw system and context model for NUML LMS.
Task # 4: Draw a system and context model for an e-commerce website.
Lab #3: Identify Requirements Sources and Apply Kano Model
Objective
The objective of the lab is to teach students to identify different sources for eliciting
requirements and to apply the Kano Model in order to categorize the requirements.
Theoretical Description
Requirement Sources
 Stakeholders:
Stakeholders are people or organizations that (directly or indirectly) influence the
requirements of a system. Examples of stakeholders are users of the system, operators of the
system, developers, architects, customers, and testers.
 Documents:
Documents often contain important information that can provide requirements. Examples of
documents are universal documents, such as standards and legal documents, as well as
domain- or organization specific documents, such as requirements documents and error
reports of legacy systems.
 Systems in Operation
Systems in operation can be legacy or predecessor systems as well as competing systems. By
giving the stakeholders, a chance to try the system out, they can gain an impression of the
current system and can request extensions or changes based on their impressions.
Missing Stakeholders
If stakeholders are not identified or not considered, it may result in significant repercussions
for the project progress because requirements may remain undetected. At the latest, these
overlooked requirements will enter the picture in the form of change requests during system
operation. Fixing these issues retroactively causes high additional costs. Therefore, it is
essential to identify all stakeholders and integrate them into the elicitation procedures.
Handling Stakeholders
In order to manage stakeholders’ data, use tables and spreadsheets that contain (at least) the
following data:
 name
 function (role)
 additional personal and contact data
 temporal and spatial availability during the project progress
 relevance of the stakeholder
 area and extent of expertise of the stakeholder
 and the stakeholder’s goals and interests regarding the project
 A sample sheet containing stakeholder information for the Library Management System is
provided. See Table 1.
Table 1: Stakeholder Information for Library Management System

Temporal Relevance of Area and Stakeholder’s

Function Additional Personal and and Spatial the Extent of Goals and
Name (Role) Contact Data Availability Stakeholder Expertise Interests

Streamline book
Library
Email: Available M- cataloguing,
Mary Library operations,
mary.anderson@library.c F, 9 AM - 5 High borrowing, and
Anderson Admin Inventory
om, Phone: 123-456-7890 PM, On-site returning
management
processes

Improve user
User
Email: Available M- experience and
David services,
Librarian david.johnson@library.co F, 10 AM - 6 High facilitate easy
Johnson Information
m, Phone: 123-456-7891 PM, On-site access to
management
resources

IT Ensure system
Email: Available M-
Lisa IT infrastructure stability and
lisa.brown@library.com, F, 8 AM - 4 Medium
Brown Support , Technical provide ongoing
Phone: 123-456-7892 PM, On-site
support technical support

Ensure easy
Email: Student
Student Available T- access to library
Michael michael.green@universit needs,
Represent F, 11 AM - 7 Medium resources and
Green y.com, Phone: 123-456- Resource
ative PM, On-site improve search
7893 utilization
functionalities

Facilitate
Academic research by
Available M-
Email: research, ensuring
Emma Faculty W, 9 AM - 3
emma.white@university.c Medium Resource availability of
White Member PM, On-
om, Phone: 123-456-7894 recommendat required
site/Remote
ions academic
resources
Align library
Email: Available M- Strategic
Library services with
Robert robert.king@libraryboard. F, 9 AM - 6 planning,
Board High strategic goals
King com, Phone: 123-456- PM, On- Library
Member and policy
7895 site/Remote policies
requirements

Ensure the
Facility physical upkeep
Email: Available M-
Maintena maintenance, of the library and
Sarah Lee sarah.lee@library.com, F, 7 AM - 3 Low
nce Staff Equipment support the
Phone: 123-456-7896 PM, On-site
handling integration of the
new system
Kano Model
Knowing the importance of a requirement for the satisfaction of the stake holders is very
helpful for requirements elicitation. Along with the respective properties of a product that
determine the satisfaction, the satisfaction is classified into the following three categories:

• Dissatisfiers (sub-conscious requirements) are properties of the system that are self-
evident and taken for granted (subconscious knowledge).

• Satisfiers (conscious requirements) are explicitly demanded system properties

(conscious knowledge).

• Delighters (unconscious requirements) are system properties that the stakeholder

does not know or expect and discovers only while using the system—a pleasant and
useful surprise (unconscious knowledge).
Example: Kano Model for Library Management System
Dissatisfiers (Self-evident properties)
 Basic Search Functionality: The system must allow users to search for books by title,
author, or ISBN.
 Borrowing and Returning: The system must manage the borrowing and returning of
books, including due dates and overdue fines.
 User Authentication: Users (students, faculty, and staff) must be able to log in
securely to the system.
 Inventory Management: The system must keep an accurate inventory of all books and
resources in the library.
 Basic Reporting: The system must provide basic reports on borrowed books, overdue
items, and inventory status.
Satisfiers (Explicitly demanded system properties)
 Advanced Search Options: Users should be able to filter search results by category,
publication year, genre, etc.
 Reservation System: Users should be able to reserve books that are currently checked
out.
 Notifications: The system should send email or SMS notifications for due dates,
overdue books, and reserved books available for pickup.
 User Profile Management: Users should be able to update their personal information
and view their borrowing history.
 Integration with Online Databases: The system should integrate with external
academic databases and online resources.
 Multi-language Support: The system should support multiple languages for diverse
user groups.
Delighters (Pleasant and useful surprises)
 Recommendation System: The system could suggest books to users based on their
borrowing history and preferences.
 Mobile App: Providing a mobile app for accessing the library management system on
the go.
 Self-Checkout Kiosks Integration: Allowing users to check out books using self-
service kiosks in the library.
 Virtual Library Tours: Offering virtual tours of the library and its resources through
the system.
 Analytics and Insights: Advanced analytics to provide insights on reading trends,
popular books, and user engagement.
 Social Features: Allowing users to share their reading lists, reviews, and
recommendations with friends within the system.
Lab Task:
Task#1: Consider example scenario of Weather Forecasting Application. Identify
requirements of sources and categorize the requirements of the mentioned system
according to Kano Model.
Task#2: Consider example scenario of Internet Browser. Identify requirements of
sources and categorize the requirements of the mentioned system according to Kano
Model.
Lab #4: Requirements Elicitation Techniques
Objective
The objective of the lab is to instruct students to apply various elicitation techniques in order
to systematically gather comprehensive requirements for the software systems.
Theoretical Description
Requirement Elicitation Techniques
 Survey Techniques (Questionnaire, Interview)
 Creative Techniques (Brainstorming, Change of Perspective, Analogy Technique)
 Document-centric Techniques (System archaeology, Perspective-based reading, reuse,
 Observation Techniques (Question observation and optimize processes, field
observation, apprenticing)
 Support Techniques (Mind mapping, workshops, CRC Cards, Audio and Video
recordings, Modelling action sequences, Prototypes for illustration)
Survey Techniques:
1. Interviews
Steps for Interviews
 Selecting Interviewees
 Designing the Interview Guide
 Preparing for the Interview
 Conducting the Interview
 Post-Interview Follow-up
Sample Interview Questions for an Ecommerce Store:
Business Owner/Manager:
 What are the main objectives you aim to achieve with the ecommerce store?
 Can you provide an overview of the products or services you intend to sell through
the platform?
 Who is your target audience, and what demographics are you focusing on?
 Do you have any specific branding guidelines or visual identity that should be
reflected in the design of the store?
 How do you plan to manage inventory, orders, and fulfillment processes?
 What sets your ecommerce store apart from competitors in your industry?
Marketing/Sales Team:
  What strategies do you plan to employ to attract and retain customers?
 Can you describe the ideal customer journey or sales funnel for your ecommerce
platform?
 Are there any particular integrations or tools you require to execute your marketing
campaigns effectively?
 How do you envision leveraging data analytics to optimize marketing efforts and
improve sales performance?
 What are your expectations regarding product recommendations, upselling, and cross-
selling features?
Customer Support:
 What channels do you plan to offer for customer support, and why?
 How do you intend to handle customer inquiries and complaints efficiently?
 Are there any specific features or functionalities you believe are essential for
providing excellent customer service?
 Do you anticipate any common issues or challenges that customer support might face,
and how do you plan to address them?
 What metrics will you use to measure the effectiveness of your customer support
efforts?
IT/Development Team:
 What technology stack do you prefer for building the ecommerce platform, and why?
 Are there any existing systems or databases that need to be integrated with the
ecommerce store?
 What scalability and performance requirements do you have for the platform?
 How do you plan to ensure the security and compliance of the ecommerce store?
 What are your priorities when it comes to user experience, performance optimization,
and mobile responsiveness?
Design/UI/UX Team:
 Can you describe your vision for the design and user interface of the ecommerce store?
 What are your brand guidelines, and how should they influence the design?
 What specific design elements or features do you believe will enhance the user
experience?
 How important is mobile responsiveness and accessibility for your target audience?
 Are there any design inspirations or references you would like us to consider?
Payment and Checkout:
 Which payment methods do you plan to support on the ecommerce platform?
 What are your expectations regarding the checkout process and user flow?
 Are there any specific requirements for managing customer payments and order
transactions securely?
 How do you plan to handle issues such as abandoned carts and failed transactions?
 Do you have any preferences for integrating third-party payment gateways or billing
systems?
Legal/Compliance:
 Are there any legal or regulatory requirements that the ecommerce store must adhere
to?
 Do you need assistance with drafting terms of service, privacy policies, or other legal
documents?
 Are there any restrictions on the sale of certain products or services that we need to be
aware of?
 How do you plan to address issues related to data privacy and consumer protection
laws?
 Do you foresee any potential legal risks or challenges that we should consider during
the development process?
Feedback and Additional Requirements:
 Is there any additional information or specific requirements you would like to share
with the development team?
 Do you have any feedback or suggestions for improving the ecommerce platform or
the development process?
 Are there any concerns or challenges you anticipate during the implementation phase,
and how can we mitigate them?
 What are your expectations regarding communication and collaboration between
different stakeholders throughout the project?
 Do you have a preferred timeline and budget for the development and launch of the
ecommerce store?
2. Questionnaires
Making use of open and/or closed questions (e.g., multiple choice questions) is another way
of eliciting requirements from stakeholders. If there are a large number of participants that
must be surveyed, an online questionnaire is a viable option. Questionnaires can elicit a
magnitude of information in a short amount of time and at low costs. As long as answers are
predetermined, even stakeholders that are not able to explicitly express their knowledge can
deliver an assessment. A disadvantage of using a questionnaire is that it can be only employed
to gather requirements the requirements engineer already knows or conjectures.
Important pints to be considered while designing questionnaire for eliciting requirements:
1. Understand the Audience:
 Know who the stakeholders are, their roles, technical expertise, and familiarity
with the project.
 Tailor questions to suit the knowledge level and interests of the respondents.
2. Define Clear Objectives:
 Clearly outline the purpose of the questionnaire.
 Determine what specific information you need to gather to inform the requirements.
3. Structure and Format:

 Organize the questionnaire logically, grouping similar questions together.

 Use a mix of question types (e.g., multiple-choice, open-ended, rating scales) to
gather both quantitative and qualitative data.
 Keep the questionnaire concise to respect the respondent's time, but ensure it is
comprehensive enough to gather all necessary information.
4. Clarity and Precision:
 Use clear, simple, and unambiguous language.
 Avoid jargon and technical terms unless you are sure the audience understands
them.
5. Avoid Leading Questions:
 Ensure questions are neutral and do not suggest a particular answer.
 Allow respondents to express their opinions and preferences freely.
6. Pilot Testing:
 Test the questionnaire with a small group of stakeholders or colleagues to identify
any issues or ambiguities.
 Use feedback from the pilot test to refine and improve the questionnaire.
Some other points to be noted:
1. Introduction:
 Start with a brief introduction explaining the purpose of the questionnaire, how
the data will be used, and the importance of their input.
  Include instructions on how to complete the questionnaire.
2. Demographic Questions:
 Collect basic demographic information if relevant, such as the respondent’s role,
department, experience, and familiarity with the project.
3. Current System Evaluation:
 Ask questions about the current system or processes, if applicable, to understand
existing pain points, strengths, and areas for improvement.
4. Requirements Gathering:
 Use open-ended questions to allow stakeholders to provide detailed feedback on
their needs and expectations.
 Include specific questions about desired features, functionality, performance, and
usability.
5. Prioritization:
 Ask respondents to prioritize their requirements or rate the importance of various
features and functionalities.
6. Scenarios and Use Cases:
 Use scenario-based questions to understand how stakeholders envision using the
system.
 Ask for specific examples or use cases to gather context-specific requirements.
7. Validation and Verification:

 Include questions that help verify the feasibility and practicality of the requirements.
 Ask stakeholders about potential challenges or constraints.
8. Feedback and Suggestions:
 Provide space for additional comments, suggestions, or concerns that may not have
been covered by the structured questions.
9. Closing:
 Thank the respondents for their time and contributions.
 Provide contact information for any follow-up questions or further clarification.
Creative Techniques:
Creativity techniques serve the purpose of developing innovative requirements, delineating an
initial vision of the system, and eliciting excitement factors.
 1. Brainstorming
During brainstorming, ideas are collected within a certain time frame, usually in groups of 5 to
10 people. The ideas are documented by a moderator without discussing, judging, or
commenting on them at first. Participants use ideas of other participants to develop new
original ideas or to modify existing ideas. After that, the collected ideas are subjected to a
thorough analysis.
2. Change of Perspective
Among the techniques that employ a change of perspective (adopting different extreme
standpoints), the most common technique is the so-called Six Thinking Hats. Each of the six
hats represents a particular perspective that is in turn adopted by each of the participants. The
resulting solutions approach the problem from different standpoints. That way, even
stakeholders that are very convinced of their own opinion are persuaded to adopt a different
standpoint.
3. Analogy
In bionics, problems that the project faces are mapped to an analogous situation occurring in
nature, and the solutions nature provides are sought and then mapped back to the project. In
bisociation, the analogies need not originate in nature. These techniques assume that each
participant is capable of analogous thinking, that a lot of time is available, and that the
participants have an in-depth knowledge of the domain with which an analogy will be drawn.
Analogy techniques can be applied covertly or in the open. When this technique is applied
covertly, the participants are only told the analogy.
Bionics Example: Efficient Data Routing in a Network
Scenario: Developing an efficient data routing protocol for a distributed network system.
Analogous Situation in Nature: Foraging behaviour of bees.
Problem: Ensuring efficient data transfer and minimal congestion in a distributed network
where nodes must dynamically find the best routes for data packets.
Natural Solution: Bees use a decentralized approach to find the best flowers for nectar by
sharing information about food sources through the waggle dance, optimizing for energy
efficiency and distance.
Mapping Back to the Project:
 Study Bee Behaviour: Understand how bees communicate and optimize their foraging
routes using the waggle dance.
 Identify Requirements: Requirements might include decentralized communication
protocols, dynamic route discovery, and adaptive load balancing.
 Design Routing Protocol: Develop a data routing protocol that mimics the bee's
foraging behaviour, where nodes share information about optimal routes, dynamically
adjust to changes, and avoid congested paths.
Outcome: A requirements specification for a data routing protocol that optimizes for
efficiency and adaptability, inspired by the decentralized and dynamic foraging behaviour of
bees.
Bisociation Example: Hospital Patient Management System
Scenario: Creating a new patient management system for a hospital.
Analogous Situation from a Different Domain: Airline reservation and management systems.
Problem: Efficient management of patient records, appointments, and hospital resources.
Non-Natural Solution: Airline reservation systems manage large volumes of bookings,
customer records, and resource allocation efficiently.
Mapping Back to the Project:
 Study Airline Systems: Examine features such as real-time booking updates, customer
record management, and resource scheduling.
 Identify Requirements: Requirements might include real-time patient record updates,
appointment scheduling, resource allocation, and patient notification systems.
 Design Management System: Develop a patient management system that incorporates
real-time updates, automated scheduling, and efficient resource allocation inspired by
airline systems.
Outcome: A requirements specification for a hospital patient management system that
improves efficiency and patient experience through advanced scheduling and resource
management.
Lab Task:
Task 1: Scenario - Weather Forecasting App
Description: A weather forecasting app is being developed to provide users with real-time
weather updates, forecasts, and alerts. The app aims to serve both general users and
specialized users like farmers and travelers.
Task: Design a questionnaire to gather requirements from general users, farmers, and
travelers about what features they expect in a weather forecasting app.
Task 2: Scenario 2 - Internet Browser
Description: A new internet browser is being developed to offer users a fast, secure, and
customizable browsing experience. The browser targets both individual users and corporate
clients.
Brainstorming: Organize a brainstorming session to come up with innovative features and
security enhancements for the browser.
Change of Perspective: Use the change of perspective technique to think about what features
a competitor’s browser might offer and how to outperform them.
Lab #5: Requirements Elicitation Techniques
Objective
The objective of the lab is to instruct students to apply various elicitation techniques in order
to systematically gather comprehensive requirements for the software systems.
Theoretical Description
Document-centric Techniques
Document-centric techniques reuse solutions and experiences made with existing systems.
When a legacy system is replaced, this technique ensures that the entire functionality of the
legacy system can be identified. Document-centric techniques should be combined with other
elicitation techniques so that the validity of the elicited requirements can be determined and
new requirements for the new system can be identified.
1. System Archaeology
System archaeology is a technique that extracts information required to build a new system
from the documentation or implementation (code) of a legacy system or a competitor’s
system. The technique is often applied when explicit knowledge about the system logic has
been lost partially or entirely. By analyzing existing code, the requirements engineer ensures
that none of the functionalities of the legacy system will be overlooked and the system logic
of the legacy system is elicited anew.
2. Perspective-based Reading
Perspective-based reading (see section 7.5.4) is applied when documents need to be read with
a particular perspective in mind, e.g., the perspective of the implementer or the tester.
3. Reuse
Requirements that have been previously compiled and brought up to a certain quality
standard can be reused. In order to do that, the requirements are stored in a database, for
instance, and kept available at the required level of detail for reuse. Through reuse, the costs
involved with the elicitation procedures can be significantly reduced.
Observation Techniques
1. Field observation:
The requirements engineer is on location with the specialist or the users of the system and
observes and documents the processes and operational procedures that they carry out. Using
these observations, she formulates the requirements.
2. Apprenticing
With apprenticing, the requirements engineer must actively learn and perform the procedures
of the stakeholders. Just like an apprentice, the requirements engineer is encouraged to
question unclear and complex operational procedures so that she may gather domain
experience. Thereby, she can experience requirements that the stakeholders take for granted
and therefore cannot elucidate.
Support Techniques
1. Mind Mapping
A graphical representation of the refined relationships and interdependencies between terms
is created. Mind mapping is often used as a supporting technique for brainstorming or
brainstorming paradox.
2. Workshop
During a joint meeting, the requirements engineer and the stakeholders elaborate the goals (or
details of a certain functionality) of the system. For example, the necessary user interfaces of
the system can be designed in a workshop.
3. CRC Cards
With the CRC technique (CRC stands for Class Responsibility Collaboration), context
aspects and their respective attributes and properties are denoted on index cards.
Requirements are then formulated using these cards.
4. Audio and Video Recordings
Audio and video recordings are very well suited to elicit requirements when stakeholders are
not always available, when budget is tight, or when the system is highly critical. Especially
during field observations, audio and video recordings can help capture fast-paced processes.
The disadvantage of this technique is that stakeholders often feel supervised when they are
being recorded and as a result might deliver biased statements or, in extreme cases, might
even refuse to cooperate.
5. Modeling Action Sequences
Use case modeling: Use cases document the external view of the system to be developed. A
use case has a trigger event, which triggers the use case and an expected result, or outcome of
the use case. Every use case is a functionality that must be supported by the system to be
developed.
6. Prototypes for Illustration
Prototypes are well suited to question established requirements and to elicit requirements in
situations where stakeholders have only a vague understanding of what is to be developed.
Potential consequences of new or changed requirements can be identified easier. For
example, user interface prototypes are frequently used in practice to find additional functional
requirements.
Lab Tasks
Task 1: Library Management System
Description: A library is implementing a Library Management System to digitize and
streamline the management of library resources, including book cataloguing, user
management, and borrowing/returning processes.
Task: Examine existing documentation and systems to understand the current workflow and
pain points in the library's management of resources and user data. (Technique: System
Archaeology)
Task 2: NUML Learning Management System
Description: A Learning Management System (LMS) is a software application that
administers, delivers, and tracks educational courses and training programs. It facilitates
course management, content delivery, assessments, user management, communication, and
progress reporting, enhancing the overall learning experience. Consider NUML Learning
Management System and do the following.
Task: Observe and document how instructors, students, and administrators interact with the
current learning system. Note the challenges and inefficiencies. (Technique: Field
Observation)
Task 3: Weather Forecasting Application
Description: A weather forecasting application is being developed to provide users with real-
time weather updates, forecasts, and alerts, including temperature, precipitation, and severe
weather warnings.
Task: Develop simple prototypes (e.g., wireframes) to illustrate the user interface and
workflow of the weather forecasting application. Use these prototypes to gather feedback
from potential users and meteorologists. (Technique: Prototypes for illustration)
Lab #6: Documenting Requirements in Natural Language
Objective
The objective of this lab is to explore and document different methods of requirements
documentation, including natural language, conceptual models, and hybrid approaches, and to
understand the structure and quality criteria essential for effective requirements documentation.
Theoretical Description
Natural language is the most commonly applied documentation form for requirements in
practice. In contrast to other documentation forms, natural language has a striking advantage:
No stakeholder has to learn a new notation. In addition, language can be used for
miscellaneous purposes—the requirements engineer can use natural language to express any
kind of requirement. Natural-language-based documentation is well suited to document
requirements in any of the three perspectives i.e., data perspective, functional perspective,
and behavioural perspective. However, natural language can allow requirements to be
ambiguous, and requirements of different types and perspectives are in danger of being
unintentionally mixed- up during documentation. In that case, it is difficult to isolate
information pertaining to a certain perspective amidst all of the requirements in natural
language.
In contrast to natural language, the different types of conceptual models cannot be used
universally. When documenting requirements by means of models, special modeling
languages must be used that pertain to the appropriate perspective. Assuming the modeling
language selected for a documentation task is applied correctly, its use constructively
guarantees that the models created depict information pertaining to the respective perspective
only. The models depict the documented requirements much more compactly and they
therefore are easier for a trained reader to understand than is natural language. In addition,
conceptual models offer a decreased degree of ambiguity (i.e., fewer ways to be interpreted)
than natural language due to their higher degree of formality. However, using conceptual
modeling languages for requirements documentation requires specific knowledge of
modeling. The following list includes short descriptions of the most important diagrams
discussed in chapter 6.
 Use Case Diagram
 Class Diagram
 Activity Diagram
 State Diagram
Hybrid Requirements Document
Requirements documents first and foremost contain requirements. In addition, in many
situations it is sensible to document decisions, important explanations, and other relevant
information as well. Depending on the target audience of the document, the perspective on
the system, and the documented knowledge, suitable documentation types are selected.
Typically, documents contain a combination of natural language and conceptual models. The
combination allows the disadvantages of both documentation types to be decreased by means
of the strengths of the other documentation type, and combining documentation types exploits
the advantages of both. For instance, models can be amended or complemented by
natural
language comments and natural language requirements and natural language glossaries can be
summarized and their dependencies can be depicted clearly by making use of models.
Document Structures:
Requirements documents contain a magnitude of different information. These must be well
structured for the reader. In order to do that, one can make use of standardized document
structures or individually define a custom document structure.
Standardized Document Structure
The ISO/IEC/IEEE standard 29148:2011 contains an outline designed for the
documentation of software requirements.
 A chapter with introductory information
 A chapter with a listing of all documents that are referenced in the specification
 A chapter for specific requirements (e.g., functional requirements, performance,
interfaces)
 A chapter with all planned measures for verification
 Appendices (e.g., information about assumptions that were made, identified
dependencies)
Attach template for SRS.
User Requirements:
User requirements describe what the user expects from the system. They are generally high-
level and written in a manner that is understandable to the end users and stakeholders who
may not have technical expertise. Examples include the tasks users need to perform, their
interactions with the system, and the overall goals they aim to achieve.
System Requirements:
System requirements are more detailed and technical. They describe how the system will
fulfill the user requirements and specify the system's internal operations and functionalities.
These requirements are used by developers and technical teams to design and build the
system.
Functional Requirements:
These define specific behaviour or functions of the system. They describe what the system
should do, the tasks and services it must perform, and how it interacts with users and other
systems. Functional requirements are directly related to the functions and features of the
system, user interactions, data handling, and processing.
1. The system shall allow users to search for books by title, author, or ISBN.
2. The system shall allow users to create and manage personal accounts, including
registration, login, and password recovery.
3. The system shall enable users to borrow and return books, updating the inventory
accordingly.
 4. The system shall send notifications to users for book due dates and overdue books.
Non-Functional Requirements:
These specify criteria that can be used to judge the operation of a system, rather than specific
behaviours. They describe how the system performs a function, focusing on quality attributes
such as performance, usability, reliability, and security. Non-functional requirements are
Concerned with the overall qualities and constraints of the system, such as performance,
scalability, and maintainability.
1. The system shall handle up to 10,000 concurrent user sessions with a response time of
less than 2 seconds for search queries.
2. The system shall be accessible via web browsers on both desktop and mobile devices
with an intuitive and user-friendly interface.
3. The system shall use encryption for all user data, including passwords, and implement
multi-factor authentication for user login.
4. The system shall have an uptime of 99.9% and provide failover mechanisms to ensure
continuous availability.
5. The system shall be designed using modular architecture to facilitate easy updates and
maintenance without significant downtime.
Constraints
Constraints are restrictions or limitations that the system must operate within. They can be
technical, business, regulatory, or environmental factors that impact the design, development,
and operation of the system.
Technical Constraints
1. The system must be compatible with the existing library database management system.
2. The system must support web browsers on both Windows and Mac OS platforms.
Business Constraints
1. The development of the system must be completed within six months.
2. The project budget is capped at $100,000.
Regulatory Constraints
1. The system must comply with the General Data Protection Regulation (GDPR).
2. The system must adhere to the Americans with Disabilities Act (ADA) for web
accessibility.
Environmental Constraints
1. The system must be able to operate efficiently in areas with limited internet bandwidth.
2. The user interface must support multiple languages, including English, Spanish, and
French.
Lab Task
Task#1: Consider example of NUML Learning Management System, Internet Browser or
Weather Forecasting Application (anyone) and state the following:
 Functional Requirements
 Non-functional Requirements
 Constraints
Lab #7: Requirements Construction using Template
Objective
The objective of the lab is to identify and understand various challenges and pitfalls
associated with documenting requirements in natural language, such as nominalization, nouns
without reference index, universal quantifiers, incompletely specified conditions and process
verbs, and to practice constructing clear and precise requirements using templates.
Theoretical Description
Effects of Documenting Requirements in Natural Language
1. Nominalization
By means of nominalization, a (sometimes long-lasting) process is converted into a (singular)
event. All information necessary to accurately describe the process is thereby lost.
Erroneous Requirement: "The system shall perform regular updates to ensure security."
Issue: The action of performing updates is turned into a static noun "updates," potentially
hiding the frequency and process details of the updating mechanism.
Erroneous Requirement: "The application will notify users of upcoming events."
Issue: The ongoing action of notifying users is reduced to a static feature, potentially
obscuring details about timing, methods, and user interaction.
2. Noun without Reference Index
As with process verbs, nouns are frequently incompletely specified. Linguists call this a
missing or inadequate index of reference. Examples of terms that contain incompletely
specified nouns are the user, the controller, the system, the message, the data, or the function.
Erroneous Requirement: “The data retrieved from the database was analyzed to identify
trends and patterns."
Issue: "Data" refers to any information retrieved from a database, without specifying the
nature or content of the data. It could be any set of information stored in a database.
3. Universal Quantifiers
Universal quantifiers specify amounts or frequencies. They group a set of objects and make a
statement about the behavior of this set. It must be verified whether the specified behavior
really applies to all objects summarized through the quantifiers.
Erroneous Requirement: "Every transaction must be logged in the system's audit trail."
Issue: This requirement ensures that each transaction occurring within the system is recorded
in the audit trail. It indicates that logging is mandatory for all transactions without exceptions.
4. Incompletely Specified Conditions:
Requirements that contain conditions specify the behavior that must occur when the condition
is met. In addition, they must specify what behavior must occur if the condition is not met
(the part that is often missing).
Erroneous Requirement: "Users must be able to upload files of any size to the system."
Issue: The problem with this requirement is that it lacks constraints or limitations regarding
the size of the files that users can upload. Allowing users to upload files of any size could
potentially lead to performance issues, resource consumption, or system instability, especially
if large files are uploaded frequently.
Solution: "Users must be able to upload files to the system with a maximum size limit of 100
MB per file. If a user attempts to upload a file larger than the specified limit, they should
receive an error message indicating that the file exceeds the maximum allowed size."
5. Incompletely specified Process Verbs:
Some process verbs require more than one noun to be considered completely specified. The
verb transmit, for instance, requires at least three supplements to be considered complete:
what is being transmitted, from where it is being transmitted, and to where it is being
transmitted.
Erroneous Requirement: "The system must transmit messages quickly."
Issue: This requirement is vague and lacks specificity. It doesn't define what type of messages
are being transmitted, from where they are being transmitted, and to where they are being
transmitted. Additionally, "quickly" is subjective and not quantifiable.
Solution: "The system must transmit real-time location updates from the mobile application
to the tracking server within 2 seconds."
Requirements Construction using Template
Requirements templates provide a simple and easily understandable approach to reduce
language effects when documenting requirements. Templates support the author in achieving
high quality and syntactic unambiguousness in optimal time and at low costs.
 Step#1: Determine the legal obligation
 Step#2: The Requirement Core
 Step#3: Characterize the activity of a System
 Step#4: Insert Objects
 Step#5: Determine logical and temporal conditions
Step#1: Determine the legal obligation
Distinguish between legally obligatory requirements, urgently recommended requirements,
future requirements, and desirable requirements. You can use the modal verbs shall, should,
will, and may. Alternatively, the legal obligation of a requirement can be documented by a
specific requirements attribute. (Priority, Source, Comments, Difficulty, Risk)
Step#2: The Requirement Core
The core of each requirement is the functionality that it specifies (e.g., print, save, paste, or
calculate). This functionality is referred to as the process. Processes are activities and may
only be described using verbs. The process that depicts the system behavior by means
of a
requirement is to be described in step 2. Since process words determine semantics, they must
be defined as clearly as possible and be used as consistently as possible
Step#3: Characterize the activity of a System
For functional requirements, the system activity can be classified as one of three relevant types:
 Autonomous system activity: The system performs the process autonomously.
 User interaction: The system provides the process as a service for the user.
 Interface requirement: The system performs a process depending on a third party
(e.g., another system). The system is passive and waits for an external event.
Examples
 The LMS should have a recommendation system that autonomously suggests books to
users based on their borrowing history and preferences. [Autonomous Requirement]
 The system should autonomously send overdue notices to users through email or text
messages when their borrowed items are past the due date. [Autonomous
Requirement]
 The system shall allow users to place reservations on items that are currently checked
out, with automated notifications when the item becomes available. [User interaction
Requirement]
 The system should support data import/export functionality to facilitate the bulk
import of book records and other library data. [Interface Requirement]
 The LMS should provide APIs for integration with external systems, such as online
databases, e-books, or e-journal repositories. [Interface Requirement]

Autonomous system activity:

The first template type is used when requirements are constructed that depict system activities
that are performed autonomously. The user does not interact with the activity.

<Process Verb> depicts a process verb as described in step 2, e.g., print for print functionality
or calculate for some calculation that is performed by the system.
User Interaction
If the system provides a functionality to a user (for example, by means of an input interface),
or the system directly interacts with a user, requirements are constructed using template type
2:

The user that interacts with the system is integrated into the requirement through <whom?> .
Interface Requirement
If the system performs an activity and is dependent on neighboring systems, the third
template type is to be used. Whenever messages or data are received from a neighboring
system, the system must react by executing specific behavior. The following template has
proven itself as well suited:

Step#4: Insert Objects

Complete Process Verbs: Some process verbs require one or more additional objects to be
considered complete. In step 4, potentially missing objects and supplements of objects
(adverbials) are identified and added to the requirement. For instance, the requirements
template for the process verb print is amended by the information of what is being printed
and where it is printed.

Step#5: Determine Logical and Temporal Conditions

Typically, requirements do not document continuous functionalities, but functionalities that
are performed or provided only under certain logical or temporal constraints.
 Use temporal conjunction as soon as for temporal conditions and the conditional
conjunction if for logical conditions.
 The conjunction when makes not clear whether a temporal or a logical condition is
described and should therefore be avoided.
In step 5, quality requirements that describe the conditions under which a requirement is
fulfilled are added to the beginning of a requirement as a subordinate clause.

Lab Task:
Task#1: A weather forecasting app is being developed to provide users with real-time weather
updates, forecasts, and alerts. Construct requirements according to the mentioned template.
Lab #8: Model-based Requirements Documentation
Objective
To illustrate the process of requirements documentation using use case diagrams and use case
specifications, highlighting their roles in capturing system functionality, interactions, and
user goals, with practical examples to demonstrate their application in software development.
Theoretical Description
Requirement models are used in addition to natural language requirements documentation
and partly replace requirements that would have been documented using natural language.
Model:
A model is an abstract representation of an existing reality or a reality to be created. In order
to construct conceptual models, specific modeling languages are used. A modeling language
is defined by its syntax and semantics:
 Syntax: The syntax of a modeling language defines the modeling elements to be used
and specifies the valid combinations thereof.
 Semantics: The semantics defines the meaning of the individual modeling elements
and serves therefore as a foundation for the interpretation of the models of the
respective modeling language.
UML
The unified modeling language (UML) is a general-purpose visual modeling language that is
intended to provide a standard way to visualize the design of a system.
Use Cases
Use cases were first proposed as a method to document the functionalities of a planned or
existing system on the basis of simple models. The use case approach is based on two
concepts that are used in conjunction with one another, i.e. Use case diagrams and Use case
specifications.
Use Case Diagrams
Use case diagrams in the UML are simple models to schematically document the functions of
a system from a user’s perspective and to document the interrelations of the functions of a
system and the relations between these functions and their environment.
Modeling Elements of UML Use case Diagrams
 Figure 3: Essential Modeling elements of Use Case Diagram
Use Case
In the use case modeling approach, functional requirements are described in terms of actors,
which are users of the system, and use cases. A use case defines a sequence of interactions
between one or more actors and the system. In the requirements phase, the use case model
considers the system as a black box and describes the interactions between the actor(s) and
the system in a narrative form consisting of user inputs and system responses.
A use case always starts with input from an actor. A use case typically consists of a sequence
of interactions between the actor and the system. Each interaction consists of an input from
the actor followed by a response from the system. Thus, an actor provides inputs to the
system and the system provides responses to the actor. The system is always considered as a
black box, so that its internals are not revealed. Whereas a simple use case might involve only
one interaction between an actor and the system, a more typical use case will consist of
several interactions between the actor and the system. More complex use cases might also
involve more than one actor.
Consider a simple banking example in which an automated teller machine (ATM) allows
customers to withdraw cash from their bank accounts. There is one actor, the ATM
Customer, and one use case, Withdraw Funds, as shown in Figure 4. The Withdraw Funds
use case describes the sequence of interactions between the customer and the system; the use
case starts when the customer inserts an ATM card into the card reader, then responds to the
system’s prompt for the PIN, and eventually receives the cash dispensed by the ATM
machine.
 Figure 4: Example of Actor and Use Case

Names begin with a verb – A use case models an action so the name should begin with a verb.
Uses cases that are defined for the system are depicted using oval shapes. These shapes
contain the name of the use case.
Identifying Use cases
To determine the use cases in the system, it is useful to start by considering the actors and the
interactions they have with the system. Each use case describes a sequence of interactions
between the actor and the system. In this way, the functional requirements of the system are
described in terms of the use cases, which constitute a functional specification of a system.
However, when developing use cases, it is important to avoid a functional decomposition in
which several small use cases describe small individual functions of the system rather than
describe a sequence of events that provides a useful result to the actor.
Let us consider the banking example again. In addition to withdrawing cash from the ATM,
the ATM Customer actor is also allowed to query an account or transfer funds between two
accounts. Because these are distinct functions initiated by the customer with different useful
results, the query and transfer functions should be modeled as separate use cases, rather than
being part of the original use case. Thus, the customer can initiate three use cases, as shown
in Figure 5: Withdraw Funds, Query Account, and Transfer Funds.
 Figure 5: Banking System Actor and Use Cases
Actors:
Actors are outside the system boundary and represent people or systems that interact with the
system modeled. An actor represents a role played in the application domain, typically by a
human user. A user is an individual, whereas an actor represents the role played by all users
of the same type. For example, there are several customers in the Banking System, who are
all represented by the ATM Customer actor. Thus, ATM Customer actor models a user type,
and individual customers are instances of the actor.
An actor is very often a human user. For this reason, in UML, an actor is depicted using a
stick figure. In many information systems, humans are the only actors. In other systems,
however, there are other types of actors in addition to or in place of human actors. Thus, it is
possible for an actor to be an external system that interfaces to the system. In some
applications, an actor can also be an external I/O device or a timer. External I/O device and
timer actors are particularly preva lent in real-time embedded systems, in which the system
interacts with the external environment through sensors and actuators.
Actors are depicted by a stick figure that receives the name of the actor and is tagged with the
stereotype “actor”. If the actor is a system, a rectangle may be used in conjunction with the
stereotype “system”.
Primary and Secondary Actors
A primary actor initiates a use case. Thus, the use case starts with an input from the primary
actor to which the system has to respond. Other actors, referred to as secondary actors, can
participate in the use case. A primary actor in one use case can be a secondary actor in
another use case. At least one actor must gain value from the use case; usually, this is the
primary actor. An example of primary and secondary actors is shown in Figure 6. The
Remote System actor initiates the Generate Monitoring Data use case, in which the remote
system sends monitoring data that is displayed to monitoring operators. In this use case,
the Remote System is the
primary actor that initiates the use case, and the Monitoring Operator is a secondary actor
who receives the monitoring data and, hence, gains value from the use case.

Figure 6: Example of primary and Secondary Actors

System boundaries:
System boundaries within a use case diagram separate the parts of the use case that are part of
the system from the parts (people or systems) that are outside the system boundary.
Optionally, the name of the system may be denoted at the system boundary in the diagram.
Use Case Relationships
Include relation:
An include relation from one use case to another use case depicts that the interaction
sequence of the first use case includes the interaction sequence of the other use case. Few
things to consider when using the <include> relationship.
 The base use case is incomplete without the included use case.
 The included use case is mandatory and not optional.
Include relationship between use cases is shown by a dashed arrow with an open arrowhead
from the including (base) use case to the included (common part) use case. The arrow is
labeled with the keyword «include».
 Figure 7: Example of an Inclusion Use Case and Include relationships

Figure 8: Example of Inclusion Use Case

Extend relation:
Extend relationships represent exceptional or seldom invoked cases. The exceptional event
flows are factored out of the main event flow for clarity. Use cases representing exceptional
flows can extend more than one use case.
 The direction of an <extend> relationship is to the extended use case.
 It extends the base use case and adds more functionality to the system.
The use case that is extended is referred to as the base use case, and the use case that does the
extending is referred to as the extension use case. It is important to note that the base use case
does not depend on the extension use case. The extension use case, on the other hand,
depends on the base use case and executes only if the condition in the base use case that
causes it to execute is true.
Extend relationship is shown as a dashed line with an open arrowhead directed from
the extending use case to the extended (base) use case. The arrow is labeled with the
keyword «extend».

Figure 9: Example of Extend relationship

An extend relation depicts that an interaction sequence that belongs to use case A extends
some interaction sequence in use case B at a specified point. This is known as the extension
point. The extension is triggered by the condition defined.

Figure 10: An example using modeling elements of use case diagram

Generalization
In this case, the specializing use cases or actors inherit the properties of the generalizing use
case or actor. For instance, the actors “service mechanic” and “customer service
representative” can be generalized as the actor “employee”. The generalizing actor would
carry all aspects that the actors “service mechanic” and “customer service representative”
have in common (e.g., employee ID)
For example, in the banking example there might be a use case called “Pay Bills”. This can
be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.
 Figure 11: Example of Generalization Use Case
Use Case Specifications
Use cases diagrams do not document any information about the individual use cases such as
the systematic interaction between a use case and an actor.
There are different templates for textual specification of use cases. These templates define
types of information that should be documented for a use case and suggest an appropriate
structure for the information. The template references therefore document experience-based
knowledge regarding structured textual documentation of use cases.
Main Scenario and Alternate Scenario
The main sequence of the use case describes the most common sequence of interactions
between the actor and the system. There may also be branches off the main sequence of the
use case that describe less frequent interactions between the actor and the system. These
alternative sequences are deviations from the main sequence that are executed only under
certain circumstances– for example, if the actor makes an incorrect input to the system. The
alternative sequences are also described in the use case. In the Withdraw Funds use case, the
main sequence is the sequence of steps for successfully achieving a withdrawal. Alternative
sequences are used to address various error cases, such as when the customer enters the
wrong PIN and must be re prompted, when an ATM card is not recognized or has been
reported stolen, and so on. Each sequence through the use case is called a scenario. A use
case usually describes several scenarios, one main sequence and a number of alternative
sequences. Note that a scenario is a complete sequence through the use case, so a scenario
could start out executing the main sequence and then follow an alternative branch at the
decision point. For example, one of the Withdraw Funds scenarios starts with the main
sequence of the customer inserting the ATM card into the card reader, entering the PIN
number in response to the prompt but then receiving an error message because the PIN was
incorrect, and then entering the correct PIN.
Preconditions and Postconditions
Preconditions define prerequisites that must be met before the system can begin executing the
use case. The system should be able to test all preconditions to see if it’s possible to proceed
with the use case. Preconditions could describe the system state (for a use case to withdraw
cash from an automated teller machine, the ATM must contain money), but they don’t
describe the user’s intent (“I need some cash”). Checking preconditions can prevent some
errors that might otherwise take place if the system knows at the outset that it can’t
successfully complete
the use case but proceeds anyway. If the ATM is empty, it shouldn’t let a user even begin a
withdrawal transaction. This is a way to make your applications more robust. Users aren’t
likely to be aware of all of a use case’s preconditions, so the BA might need to get some input
from other sources.
Postconditions describe the state of the system after the use case executed successfully.
Postconditions can describe:
 Something observable to the user (the system displayed an account balance).
 Physical outcomes (the ATM has dispensed money and printed a receipt).
 Internal system state changes (the account has been debited by the amount of a cash
withdrawal, plus any transaction fees)
Example Use Case Diagram and Use Case Specification
Lab Task:
Generate use case diagram for the internet browser, Weather forecasting application and
NUML LMS. Generate Use case specification for the use cases.
Lab #10: Requirements Validation and Negotiation
Objective
This lab manual is designed to provide hands-on experience with the concepts of
Requirements Validation and Negotiation. The labs cover fundamental techniques, quality
aspects, validation methods, and negotiation processes crucial for effective requirements
engineering in software development.
Theoretical Description
Requirements Validation and Negotiation
Validation and negotiation during requirements engineering is meant to ensure that the
documented requirements meet the predetermined quality criteria, such as correctness and
agreement.
Quality Aspects of Requirements
A major aim of using quality criteria (e.g., completeness, understandability, agreement) in
requirements validation is to be able to check requirements systematically. In order to assure
an objective and consistent validation, it is necessary that each quality criterion is concretized
and refined. In correspondence with the overall goals of the requirements engineering
process, the validation is carried out with the following goals:
 Content: Have all relevant requirements been elicited and documented with the
appropriate level of detail?
 Documentation: Are all requirements documented with respect to the predetermined
guidelines for documentation and specification?
 Agreement: Do all stakeholders concur with the documented requirements and have
all known conflicts been resolved?
Each of the three goals implies an individual approach that focuses on specific aspects of the
quality of the requirements. Therefore, the following three quality aspects have been defined:
 Quality aspect “content”
 Quality aspect “documentation”
 Quality aspect “agreement”
A requirement should be approved for further development activities only if all three quality
aspects have been checked.
Quality Aspect “Content”
The quality aspect “content” refers to the validation of requirements with respect to errors in
the content.
Test criteria of the quality aspect “Content”
The validation of requirements about the quality aspect “content” is successful once
requirements validation has been applied to the following error types and no significant
shortcomings have been detected:
1. Completeness (set of all requirements): Have all relevant requirements for the system to
be developed (for the next system release) been documented?

2. Completeness (individual requirements): Does each requirement contain all necessary

information?
Erroneous Requirement: “The software should generate reports.”
This requirement is incomplete as it does not specify the types of reports needed, the data to
be included in the reports, the format or structure of the reports, or the intended audience for
the reports.

Revised Requirement: The software should generate monthly sales reports that include
product sales, revenue, and customer demographics. The reports should be presented in PDF
format and be accessible to managers for analysis and decision-making.

3. Traceability: Have all relevant traceability relations been defined (e.g., to relevant
requirements sources)?

Erroneous Requirement: "The system shall provide real-time updates to users about their
account status."

Traceability Relation: This requirement is linked to the user interview notes where users
expressed a need for real-time account updates (Interview Note 5), and to the stakeholder
meeting where this feature was prioritized (Stakeholder Meeting Minutes, April 2024).
4. Correctness/adequacy: Do the requirements accurately reflect the wishes and needs of
the stakeholders?

5. Consistency: Is it possible to implement all defined requirements for the system to be

developed jointly? Are there no contradictions?
Erroneous Requirement-1: “The software should be accessible for visually impaired users,
following WCAG 2.1 Level AA guidelines.”
Erroneous Requirement 2: “The system should have color-coded elements to highlight
important information.”
The requirements conflict in terms of accessibility and design choices. While one
requirement emphasizes accessibility for visually impaired users, following specific
guidelines, the other requirement introduces a design element that relies on color-coding.
This inconsistency needs to be addressed to ensure the software meets both accessibility and
design requirements.
6. No premature design decisions: Are there any forestalled design decisions present in
the requirements not induced by constraints (e.g., constraints that specify a specific
client- server architecture to be used)?
Erroneous Requirement: "The system shall use a MySQL database to store user information."
This requirement specifies the use of MySQL, which is a design decision that should be
determined during the design phase based on various factors like performance, scalability,
and compatibility.
Revised Requirement: "The system shall store user information in a database that meets
performance and scalability requirements."
Rationale: The revised requirement avoids specifying the type of database and instead
focuses on the functional need, allowing for flexibility in the design phase.
7. Verifiability: Is it possible to define acceptance and test criteria based on the
requirements? Have the criteria been defined?
Erroneous Requirement: "The software should be flexible. "
The requirement lacks specificity and measurable criteria to determine flexibility. Without
clear definitions or specific functionalities related to flexibility, it becomes challenging to
verify or assess the level of flexibility provided by the software.
8. Necessity: Does every requirement contribute to the fulfillment of the goals defined?
Erroneous Requirement: “The mobile banking application should have social media
integration to allow customers to directly share their banking activities, such as transactions
and account balances, on popular social media platforms.”
While social media integration may seem like an appealing feature to some customers, it is
not essential for the core functionality and security of a mobile banking application. It
introduces potential security risks and raises privacy concerns.
9. Feasibility
Confirm the requirement can be implemented within technical, organizational, legal, and
financial constraints.
Erroneous Requirement: “The system should process one million transactions per second on a
low-end server.”
This requirement may not be feasible due to hardware limitations. Achieving such high
transaction processing capacity on a low-end server may not be technically possible or
economically viable.
10. Unambiguous
Ensure the requirement is understood in only one way by all readers.
Erroneous Requirement: “The system should have fast performance.”
The term "fast" is subjective and open to interpretation. It does not provide a clear benchmark
or specific measurable criteria for performance.
Revised Requirement: The system should load the homepage within 3 seconds for 90% of
users.
Quality Aspect “Documentation”
The quality aspect “documentation” deals with checking requirements with respect to flaws
in their documentation or violations of the documentation guidelines that are in effect, such as
understandability of the documentation formats and the consideration of organizational or
project specific guidelines regarding the documentation of requirements but also the structure
of the requirements documents.
Four test criteria of the quality aspect “documentation”

Requirements validation with regard to the quality aspect “documentation” is successful

when requirements validation has been applied to the following error types and no significant
shortcomings have been detected:
1. Conformity to documentation format and to documentation structures: Are the
requirements documented in the predetermined documentation format? For instance, has
a specific requirements template or a specific modeling language been used to document
the requirements? Has the structure of the requirements document been maintained? For
instance, have all requirements been documented at the position defined by the document
structure?
Erroneous Requirements:
 Requirement 1: “The system should allow users to login.”
 Requirement 2: “A password is required.”
Error: The requirements are not documented in a predetermined template. The structure of the
document is not maintained.
Revised Requirements:

Requirement ID: R1

Title: User Login

Description: The system shall provide a login interface where users can enter their
credentials to access the system.
Rationale: Ensure secure access to the system.
Fit Criterion: Users must be able to log in using a valid username and password.

Requirement ID: R2

Title: Password Requirement

Description: The login interface shall require users to enter a password to gain access.
Rationale: Enhance security by verifying user identity.
 Fit Criterion: The system must not allow login without a password.

2. Understandability: Can all documented requirements be understood in the context given? For
instance, have all terms used been defined in a glossary (see section 4.7)?

Erroneous Requirement: “The system should allow users to create and manage accounts.”
Error: The term "manage accounts" is not clearly defined, leading to potential
misunderstandings.
Revised Requirement (Using a Standard Template):

Requirement ID: R3

Title: Account Management

Description: The system shall allow users to create, update, and delete user accounts.
Rationale: Provide users with the ability to manage their own accounts.
Fit Criterion: Users must be able to perform account creation, updating, and deletion actions
through the user interface.
Glossary Term:
- Manage accounts: Refers to the ability to create, update, and delete user accounts.

3. Unambiguity: Does the documentation of the requirements allow for only one
interpretation or are multiple different interpretations possi ble? For instance, does a text-
based requirement not possess any kind of ambiguity?
Erroneous Requirement: “The system should process transactions quickly.”
Errors: The term "quickly" is ambiguous and can be interpreted in multiple ways.
Revised Requirement:

Requirement ID: R4

Title: Transaction Processing Time

Description: The system shall process transactions within 2 seconds under normal load
conditions.
Rationale: Ensure timely transaction processing to enhance user experience.
Fit Criterion: Transaction processing time must not exceed 2 seconds for 95% of
transactions under normal load conditions.
4. Conformity to documentation rules: Have the predetermined documentation rules and
documentation guidelines been met? For instance, has the syntax of the modeling
language been used properly?
Example:
 Actor Mislabeling: "Customer" actor is labeled as "Cust."
 Use Case Naming: Use case names are not in verb-noun format, e.g., "Login" instead
of "User Login."
 Relationship Errors: Incorrect use of association lines; some lines are missing or
improperly connected.
Quality Aspect “Agreement”
The quality aspect “agreement” deals with checking requirements for flaws in the
agreement of requirements between stakeholders. During the course of requirements
engineering, stakeholders gain novel knowledge about the system to be developed. Due to
this additional knowledge, the opinion of the stakeholders regarding a requirement that has
already been agreed upon can change. During requirements validation, stakeholders have the
opportunity to requests changes without impairing the subsequent development activities.
Three test criteria of the quality aspect “agreement”
1. Agreed: Is every requirement agreed upon with all relevant stakeholders?
Erroneous Requirement: “The system should support multi-language interfaces.”
Errors: This requirement was documented without consulting all relevant stakeholders,
leading to disagreement among the development team and the marketing team.
Revised Requirement:

Requirement ID: R7

Title: Multi-language Support

Description: The system shall support interfaces in English, Spanish, and French.
Rationale: Cater to a diverse user base and expand market reach.
Fit Criterion: Users should be able to select their preferred language during the initial setup.
Stakeholder Agreement:
- Development Team: Agreed
- Marketing Team: Agreed
- Customer Support Team: Agreed
- Project Sponsor: Agreed
 Documentation:
- Meeting minutes dated [Date] confirming agreement from all stakeholders.

2. Agreed after changes: Is every requirement agreed upon with all relevant stakeholders
after it has been changed?
Erroneous Requirement: “The system shall generate monthly financial reports.”
Errors: This requirement was changed to generate both monthly and quarterly financial
reports without re-confirming the agreement with all stakeholders.
Revised Requirement:

Requirement ID: R8

Title: Financial Reporting

Description: The system shall generate monthly and quarterly financial reports.
Rationale: Provide comprehensive financial insights.
Fit Criterion: Users should be able to generate and view financial reports for both monthly
and quarterly periods.
Change History:
- Initial Requirement: Generate monthly financial reports.
- Changed Requirement: Generate monthly and quarterly financial reports (change requested
by Finance Department on [Date]).
Stakeholder Agreement Post-Change:
- Finance Department: Agreed
- Development Team: Agreed
- Project Manager: Agreed
- Executive Sponsor: Agreed

Documentation:
- Change request form dated [Date] with signatures from all stakeholders confirming
agreement after changes.

3. Conflicts resolved: Have all known conflicts with regard to the requirements been
resolved?
Erroneous Requirement: “The system shall integrate with external CRM software.”
Errors: There was a conflict between the IT department, which preferred an in-house solution,
and the sales team, which required specific features from external CRM software.
Revised Requirement:

Requirement ID: R9

Title: CRM Integration

Description: The system shall integrate with the Salesforce CRM software.
Rationale: Leverage Salesforce features for improved sales management.
Fit Criterion: Users should be able to access and sync data between the system and
Salesforce CRM.

Conflict Resolution:
- Issue: IT department preferred in-house solution, while the sales team required Salesforce
integration.
- Resolution: Agreement to integrate with Salesforce for the initial phase, with the potential
to develop in-house capabilities for future needs.

Stakeholder Agreement Post-Conflict Resolution:

- IT Department: Agreed
- Sales Team: Agreed
- Project Manager: Agreed
- Executive Sponsor: Agreed

Documentation:
- Conflict resolution meeting notes dated [Date] with agreed action plan and signatures from
all stakeholders confirming resolution.

Requirements Validation Techniques:

1. Commenting: During commenting, the author gives their requirements to a co-worker
for expert review, who identifies and marks quality issues like ambiguity or errors,
briefly explaining the flaws.
2. Inspections: Inspections of software or any other type of product are done to
systematically check development artifacts for errors by applying a strict process. An
inspection is typically separated into various phases: planning, overview, defect
detection, defect collection, follow-up, and reflection.
3. Walk-throughs: A walk-through is a lightweight version of an inspection. A walk-
through is less strict than an inspection and the involved roles are differentiated to a
lesser degree. The goal of a walk-through of requirements is to identify quality flaws
within requirements by means of a shared process and to gain a shared understanding of
the requirements between all the people involved.
4. Perspective-based reading: Perspective-based reading validates requirements by
checking them from different viewpoints, such as the user, software architect, and tester,
to ensure they meet desired functions, design needs, and test case derivation
requirements.
5. Validation through prototypes: Requirements validation with prototypes allows
stakeholders to experience and test requirements, identifying errors and discrepancies.
Prototypes can be throw-away, discarded after use, or evolutionary, developed further for
future use.
6. Using checklists for validation: Checklists for requirements validation consist of
questions/statements that help detect errors, considering multiple aspects in complex
environments. Sources for checklist creation include quality aspects, validation
principles, document/individual requirements criteria, auditor experiences, and error
statistics. A sample Checklist for Requirements Validation is attached herewith. See
Table 2 for reference.
Lab Task:
Task#1: Identify and correct the errors related to content, documentation, or agreement.
1. The system should be user-friendly.
2. Users should be able to reset their passwords.
3. The system should have a fast response time.
4. The system should be able to handle large volumes of data.
5. The system gotta allow users to upload files super quick.
6. (a) The system shall generate weekly sales reports.
(b) The system shall generate weekly and monthly sales reports.
Task#2: Identify and correct the errors related to content, documentation, and agreement in
the requirements you have constructed in Lab#6.
Task#3: Use the provided checklist in order to validate the requirements you have
constructed in Lab#6.

Table 2: Sample Checklist for Requirements Validation

Area Status Comments

Issue
[Yes/No]

Does the Requirement Document follow some

1
standard template?

Is the implementation priority of each

Organization 2
requirement included (with description)?

Are all internal cross-references to other

3
requirements correct?

Are all requirements written at a consistent and

Completeness 4
appropriate level of detail?
 Does the Requirements Document include all of
5
the known customer or system needs?

Is any necessary information missing from a

6
requirement? If so, is it identified as TBD?

Is the expected behavior documented for all

7
anticipated error conditions?

8 Are all requirements non-conflicting and unique?

Are all requirements written in clear, concise,

9
unambiguous language?

10 Are all requirements in scope for project?

Correctness Are all requirements free from content and

11
grammatical errors?

Can all the requirements be implemented within

12
known constraints?

Are any specified error messages unique and

13
meaningful?

14 Are requirements dependencies been identified?

Are all requirements uniquely and correctly

Traceability 15
identified?

16 Are all requirements traceable to its source?

 Do all requirements have only one
17
interpretation?

Are the functional requirements in modular form

Understandab 18 with each function explicitly identified?
ility
19 Is there a glossary of terms?

20 Is formal language used?

21 Is the language un-ambiguous?

22 Are names indicative of their meaning?

Is each concept defined only once, with one clear

Clarity 23
meaning?

24 Is each statement written as clearly as possible?

Do the requirements provide an adequate basis

Special Issues 25
for design and testing?

Are all requirements actually requirements, not

26
design or implementation solution?

Total Defects
found
Lab#11: Requirements Management and Prioritizing
Requirements
Objective
The objective of the lab for requirements management is to train participants in effectively
managing requirements throughout the project lifecycle, including assigning attributes,
establishing traceability, versioning, condensing views, and prioritizing requirements.
Theoretical Description
Requirements management comprises purposefully assigning attributes to requirements,
defining views on requirements, prioritizing requirements, and tracing requirements as well
as versioning requirements, managing requirements changes, and measuring requirements.
Requirements management includes the management of individual requirements as well as
the management of requirements documents.
Attribute Scheme
The set of all defined attributes for a class of requirements (e.g., functional requirements,
quality requirements) is called an attribute scheme. Attribute schemes are usually tailored to
meet the individual project’s needs. The reader of the requirement (e.g., the contractor,
product manager, developer, project manager) can find information of the same type in the
same position (e.g., the requirement stability is always in the template section “stability”). It
is harder for her to overlook important information and that this information, supported by
the structure of the template and the predetermined attribute values, can be documented
purposefully and correctly.

Figure 12: Example of Requirement Attribute Scheme

Example: Attached is the sample sheet for requirements with assigned attributes for an
ecommerce system.
 Table 3: Requirements after assigning Attributes

Effort
Person Required
stem Respon Requiremen Validation (Person- Legal
ature Requirement Name Author Sources sible Stability t Type Status Days) Obligation

Compliance
Users should be able Market research, Product
Developme Functional 1 person for with data
enticat to register and log in Stakeholder Manage Stable Agreed
nt Team Requirement 2 days protection
securely interviews r
regulations

The system must Competitor

display a catalogue of analysis,
uct UX Product Functional 1 person for
products with images, Business Stable Agreed -
logue Designer Owner Requirement 2.5 days
descriptions, and requirements
prices document

Users should be able

Stakeholder
pping to add items to a Business Scrum Functional 1 person for
requirements Stable Agreed -
shopping cart and Analyst Master Requirement 3 days
workshop
proceed to checkout

The system must Payment

Compliance
securely process Payment gateway
ment Technic Functional 1 person for with paymen
payments using Service documentation, Stable Agreed
essing al Lead Requirement 3.5 days card industry
various payment Provider Security
standards
methods standards

Admins should be
er able to manage orders, Stakeholder
Product Product Functional 1 person for
ageme including tracking, requirements Stable Agreed -
Manager Owner Requirement 3 days
cancelling, and workshop
updating status

Compliance
Users should have Customer
Customer Product with
omer access to customer feedback, Functional 1 person for
Support Manage Stable Agreed customer
port support via live chat Support ticket Requirement 2.5 days
Team r service
and email data
standards
 The system must be
ile Market trends, Non-
responsive and Developme Product 1 person for
onsive Mobile usage Stable Functional Agreed -
optimized for mobile nt Team Owner 2 days
statistics Requirement
devices

The system should

Sales data
suggest related or Product
s- Marketing analysis, Functional 1 person for
complementary Manage Stable Agreed -
ng Team Marketing Requirement 2.5 days
products to users r
strategy
during checkout

The system must track Compliance

Inventory
ntory inventory levels and with
Operations management Product Functional 1 person for
ageme update product Stable Agreed inventory
Team system Owner Requirement 3.5 days
availability in real- control
requirements
time regulations

Users should be able

User feedback,
hlist to add products to a UX Product Functional 1 person for
Wishlist feature Stable Agreed -
ure wishlist for future Designer Owner Requirement 2 days
analysis
purchase

The system should Market Compliance

support multiple expansion with
alizatio Localizatio Product Functional 1 person for
languages and strategy, Stable Agreed internationali
n Team Owner Requirement 3 days
currencies for Localization zation
international users requirements standards

Social media
al Users should be able integration
Marketing Product Functional 1 person for
ia to share products on requirements, Unstable Conflicted -
Team Owner Requirement 3.5 days
gration social media platforms User engagement
strategy

Users should be able User feedback,

uct UX Product Functional 1 person for
to leave reviews and Review feature Unstable Conflicted -
ews Designer Owner Requirement 2.5 days
ratings for products analysis
 Users should be able Gift card Legal
to purchase and Business program Product Functional 1 person for compliance
Cards Unstable Conflicted
redeem gift cards for Analyst requirements, Owner Requirement 4 days with gift card
products Revenue strategy regulations
Requirements Prioritization
Requirements are prioritized during requirements engineering using different prioritization
criteria in all sub-activities. Requirements can be prioritized by their order of implementation,
for example. Due to the different prioritizations in the various sub-activities, the priority of a
requirement can be determined by one or more attributes (e.g., priority of the contractor,
priority due to urgency of implementation).
In order to prioritize a set of requirements, a goal (i.e., purpose) of prioritization must be
defined first. In addition, the constraints of prioritization are documented, such as the
availability of different stakeholders and groups thereof or the resources available for
prioritization.
Depending on the goal of prioritization, the criterion for prioritizing the requirements (or the
combination of two or more criteria) is chosen. The following are typical examples of
prioritization criteria:
 Cost of implementation
 Risk
 Damage due to unsuccessful implementation
 Volatility
 Importance
 Duration of implementation (i.e., how long it takes to be implemented)
Techniques for Requirements Prioritization
For prioritization, multiple techniques exist. The techniques mainly differ with regard to the
time and effort needed but also with regard to the suit ability of the different prioritization
criteria and project properties.

1. Ranking and Top-Ten Technique

 Ranking: In this technique, a number of selected stakeholders arrange the

requirements to be prioritized with respect to a specific criterion.

 Top-Ten Technique: In this technique, the n most important requirements for a

defined criterion are selected. For these requirements, a ranking order is determined
afterward. This ranking order represents the importance of the selected requirements
with regard to the defined criterion.

2. Single-criterion Classification
Another prioritization technique that is often used in practice is based on the classification of
requirements with respect to the importance of the realization of the requirements for the
system’s success. This type of prioritization is based on assigning each requirement to one of
the following priority classes.
 Mandatory: A mandatory requirement is a requirement that must be implemented at
all costs or else the success of the system is threatened.
 Optional: An optional requirement is a requirement that does not necessarily need to
be implemented. Neglecting a few requirements of this class does not threaten the
success of the system.
 Nice-to-have: Nice-to-have requirements are requirements that do not influence the
system’s success if they are not implemented.

3. Kano Classification
Kano Model Can classify and prioritize requirements with respect to their acceptance in the
market.
 Dissatisfiers: A requirement specifies a dissatisfier the system must possess in order
to be successfully introduced to the market.
 Satisfiers: A requirement specifies a satisfier if the customers consciously demand
the associated property. Satisfiers of the system specify the degree of satisfaction of
the customer. An increase in the number of satisfiers usually leads to increased
customer satisfaction.
 Delighters: A requirement specifies a delighter if the customers do not consciously
demand the defined system property, or the customers do not expect the
implementation of the property. Customer satisfaction increases exponentially by
implementing delighters.

4. Three Level Scale

5. MOSCOW Technique
Instead of numbers, this method uses four priority groups: MUST have, SHOULD have,
COULD have, and WON'T have. The acronym represents the following:
 MUST (Mandatory)
 SHOULD (Of high priority)
 COULD (Preferred but not necessary)
 WOULD (Can be postponed and suggested for future execution)

6. Bubble Sort Technique

To prioritize requirements using bubble sort, you take two requirements and compare them
with each other. If you find out that one requirement should have greater priority over the
other, you swap them accordingly. You then continue in this fashion until the very last
requirement is properly sorted. The result is a list of requirements that are ranked.
Lab Tasks
Task#1: Use the provided template for the attribute scheme and manage your requirements in
that specified format. You can also add more elements in the attribute scheme as per the
project requirement.
Task#2: Prioritize the requirements you have constructed in Lab #6 according to following
prioritization techniques.
 Kano Model
 Ranking and Top-Ten Technique
Lab#12 Traceability of requirements
Objective
The objective of the lab is to get an understanding of requirements traceability and applying
requirements traceability techniques
Theoretical Description
Requirements management comprises purposefully assigning attributes to requirements, An
important aspect of requirements management is ensuring the traceability of requirements.
The traceability of a requirement is the ability to trace the requirements over the course of the
entire life cycle of the system.tracebility of requirement has following objectives
1. Traceability of requirements allows verifying whether a requirement has been
implemented in the system, i.e., if the requirement has been implemented through a
system property.
2. Traceability of requirements allows for the identification of gold-plated solutions of
the developed system
3. Traceability of requirements allows for the analysis of effects during change
management
Types of requirements tracebility
Representation of requirements tracebility
Requirements traceability information can be represented in different ways. The most
common approaches to representing traceability are simple textual references, hyperlinks,
and trace matrices and trace graphs
1. Text-Based References and Hyperlinks
This simple way to represent traceability information of a requirement consists of annotating
the target artifact as a textual reference in the requirement (initial artifact) or to establish a
hyperlink between the initial artifact and the target artifact. When linking artifacts, different
types of hyperlinks with specific link semantics can be used.
2. Trace Matrices
Another common technique for representing and documenting traceability information
between requirements as well as between requirements and previous and posterior artifacts in
the development process are trace matrices. The rows in a trace matrix contain the initial
artifacts (requirements). In the columns, the target artifacts (e.g., sources of requirements,
development artifacts, requirements) are represented. If a trace link exists between an initial
artifact in row n and a target artifact in column m, cell (n, m) is marked in the trace matrix.
For example

3. Trace graphs
A trace graph is a graph in which all nodes represent artifacts and all edges represent
relationships between artifacts. The distinction between different artifacts and types of
traceability can be realized by means of assigning different attributes to the nodes and edges
of the graph
for example

Lab tasks
Q1 Consider a student registration and write down functional and non functional requirements
for it
Q2 In context to its requirements mentioned in Question 1 , apply pre RS traceability
relations, Post RS traceability relations and traceability between requirements
Q3.Consider the project assigned to you and apply appropriate requirement tracebility
techniques on it
Lab #13: Requirement configuration and change management
Objective
The objectives of this lab is to understand the purpose of configuration management and how
to handle change management. The techniques used to manage requirement changes and
understand the tasks performed by change control board

Theoretical description
A requirements configuration consists of a set of requirements with the additional condition
that each selected requirement is present in the requirements configuration with exactly one
version, identified by the version number. Managing configurations of requirements can be
described in two dimensions . In the product dimension, configuration management deals
with individual requirements within the requirements base (foundation). In the version
dimension, configuration management considers the various change states as part of version
management within the product dimension.
Figure shown below illustrates both dimensions of configuration management of
requirements. On the requirements axis, requirements are represented. On the version axis,
the different versions of the requirements are depicted

A configuration of requirements has the following properties:

1. Logical connection: The requirements contained in a configuration are directly
logically connected to one another, i.e., a goal-oriented grouping of the requirements
to a common configuration has been performed.
 2. Consistency: The requirements contained in a configuration do not contradict one
another, i.e., the configuration contains requirements that are contradiction free in
their respective version.
3. Unique identification: A configuration has a unique identifier (ID) which can be
used to uniquely identify the configuration.
4. Immutable: A configuration defines a certain, immutable state of the specification. If
requirements of a configuration are changed, a new version of the requirements and
potentially of the configuration is the result.
5. Basis for rollbacks: If changes of requirements must be undone, configurations offer
the ability to roll back requirements to a specific version within a configuration.
Therefore, a consistent state of the specification can be maintained
Change control board
Over the course of the system life cycle, it is necessary to channel change requests for
requirements and define a structured process that will lead to a justified decision about
whether a change request is approved and how itis approved. Changes can pertain to
individual requirements (e.g., redefining a requirement) or the entire requirements document.
The evaluation of requirements changes, as well as the decision about performing the change,
is usually the responsibility of a change control board.It is responsible for following tasks
1. Estimate the effort for performing the change (potentially commission a third party
with an effort analysis).
2. Evaluate change requests, e.g., with respect to the effort/benefit ratio.
3. Define requirement changes or define new requirements on the basis of change
requests.
4. Decide about acceptance or rejection of change requests.
5. Classify incoming change requests.
6. Prioritize accepted change requests.
7. Assign accepted change requests to change projects

The change Request

A change request should contain the following information:
1. Identifier: The identifier makes it possible to uniquely identify a change request at
any point during the life cycle of the system.
2. Title: The title summarizes the key concern of the change request in one brief
statement.
3. Description: The description documents the requirement change as precisely as
possible. It can contain information on the effect of the changes as well.
 4. Justification: The most important reasons as to why the change is necessary are listed
here.
5. Date filed: The date at which the change request was filed.
6. Applicant: The name of the person that issued the change request.
7. Priority (in the applicant’s opinion): The importance of the change request according
to the applicant’s opinion.

Lab tasks
1. Create a configuration management plan of your project
2. Identify the changes that needs to be done in the project and prepare a change request
form for each of the highlighted change