DEPARTMENT OF CSE

COURSE NAME – ADAPTIVE SOFTWARE ENGINEERING

COURSE CODE – 22CS2119R

SESSION - 7

REQUIREMENTS DEVELOPMENT METHODOLOGY

&
SPECIFYING REQUIREMENTS
 Aim of the session
• To familiarize students with the basic concept of requirement development methodology.
• To familiarize students with the process of specifying the requirements.
Instructional Objectives
This Session is designed to:
• Demonstrate the process of requirements development methodology
• List out the differences of functional and non-functional requirements
• Describe the stages in documenting the requirements
• Demonstrate the basic elements of requirement model
• List out the types of elements of requirement model
Learning Outcomes
At the end of this session, you should be able to:
• Describe the process of gathering the requirements
• Summarize functional and non-functional requirements
• Summarize the types of elements of requirement model.
 AGENDA
 What is Requirements ?  Elements of the Requirements Model
 Types of requirements  Types of Elements of the requirements
• Functional requirements • Scenario-based elements
• Non-functional requirements • Class-based elements
• Domain requirements • Behavioral elements
 Requirements engineering • Flow-oriented elements
 Stages of requirement engineering • Analysis Patterns
Requirement:
• The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as:
A condition or capability needed by a user to solve a problem or achieve an objective
• Why do we need requirements in software engineering?
 Requirements specify what features a product should include and how those features should
work.
 They help to define the test criteria, which is vital for verification and validation.
 This activity takes place when creating a new product as well as when modifying or making
changes to an existing product
Categories of requirements:
• Functional
• Non Functional
• Domain requirements

Functional Requirements:
• “Any Requirement Which Specifies What The System Should Do.”
• A functional requirement will describe a particular behavior of function of the system when
certain conditions are met.
 Example: “Send email when a new customer signs up”
•Some of the more typical functional requirements include:
– Business Rules
– Transaction corrections, adjustments and cancellations
– Administrative functions
– Authentication & Authorization levels
– Audit Tracking
– External Interfaces
– Certification Requirements
– Reporting Requirements
– Historical Data, Legal or Regulatory Requirements
Non-Functional Requirements or Non-Behavioral Requirements:
• These are basically the quality constraints that the system must satisfy according to the project
contract.
• The priority or extent to which these factors are implemented varies from one project to other.
• They basically deal with issues like:
 Portability, Security
 Maintainability, Reliability
 Scalability, Performance
 Reusability and
 Flexibility
Differences between functional and non-functional requirements:
Functional Requirements Non Functional Requirements
A functional requirement defines a system or its A non-functional requirement defines the quality attribute
component & easy to define. of a software system & difficult to design.

It places constraints on “How should the software system

It specifies “What should the software system do?”
fulfill the functional requirements?”

Non-functional requirement is specified by technical

Functional requirement is specified by User. peoples e.g. Architect, Technical leaders and software
developers.

It is mandatory & captured in use case. It is not mandatory & captured in quality attribute.
Defined at a component level. Applied to a system as a whole.
Helps you verify the functionality of the software. Helps you to verify the performance of the software.

Functional Testing like System, Integration, End to End, Non-Functional Testing like Performance, Stress,
API testing, etc are done. Usability, Security testing, etc are done.
Domain:
• A field of study that defines a set of common requirements, terminology, and functionality for
any software program constructed to solve a problem in the area of computer programming,
known as domain.
• The word domain is also taken as a synonym of application domain.
Domain requirements:
• The collection of domain requirements is a continuous process of proactively defining
the requirements for all foreseeable applications to be developed in the software product line.
• A particular issue in domain requirements is to identify and explicitly document the external
variability.
Requirement Engineering:
The process of defining, documenting and maintaining the requirements. It is a process of
gathering and defining service provided by the system.
Stages in Requirement Engineering:
• Inception—ask a set of questions that establish basic understanding of the problem, the people
who want a solution, the nature of the solution that is desired, the effectiveness of preliminary
communication and collaboration between the customer and the developer.
• Elicitation—elicit requirements from all stakeholders.
• Elaboration—create an analysis model that identifies data, function and behavioral
requirements.
Stages in Requirement Engineering (Contd.):
• Negotiation—agree on a deliverable system that is realistic for developers and customers
• Specification—can be any written document, set of models, collection of user scenarios (use-
cases), prototype
• Validation—a review mechanism that looks for errors in content or interpretation, areas where
clarification may be required, missing information, inconsistencies (a major problem when
large products or systems are engineered), conflicting or unrealistic (unachievable)
requirements.
• Requirements management - is a set of activities that help the project team identify, control,
and track requirements and changes to requirements at any time as the project proceeds.
Establishing the groundwork:
• Identify Stakeholders- A stakeholder as “ anyone who benefits in a direct or indirect way from
the system which is being developed.
• Recognizing multiple viewpoints - The Marketing group, Business Mangers, Software
Engineers, Support Engineers
• Working toward collaboration - Identify areas of commonality and areas of conflict or
inconsistency, stakeholders collaborate by providing their view of requirements, but a strong
project champion, may make the final decision about which requirements make the cut.
• Asking the First Questions - context free questions, questions that gain a better understanding
of the problem and allows the customer to voice his or her perceptions about a solution.
 1.SCENARIO-BASED ELEMENTS

Use Case Diagram for Safe home Activity Diagram for safe home
2. CLASS-BASED ELEMENTS

Class Diagram for Sensor

3. BEHAVIOURAL ELEMENTS

State Representation for Sensor

 4. FLOW-ORIENTED ELEMENTS:
– Information is transformed as it flows through a computer-based system.

– The system accepts input in a variety of forms; applies functions to transform it; and
produces output in a variety of forms.
4.ANALYSIS PATTERNS (CONTD.)
 Self Assessment Questions
1. Define Software Requirement.
2. Differentiate functional and non functional requirements.
3. Explain about the significance of domain requirements.
4. Explain various stages of requirement engineering with an example.
5. What are different types elements of requirement model.
6. Illustrate Scenario based elements in detail with an example.
7. Differentiate Class-based and behavioral elements.
8. Explain about Analysis Pattern.
TEXT BOOKS:
• Roger S.Pressman, “Software Engineering – A Practitioner’s Approach” 7th Edition, Mc Graw
Hill,(2014).
• Ian Sommerville, “Software Engineering”, Tenth Edition, Pearson Education, (2015).
Reference Book
• Agile and Iterative Development: A Manager's Guide, Craig Larman, Addison-Wesley
WEB REFERNCES/MOOCS:
https://www.digite.com/kanban/what-is-kanban/
http://www.scaledagileframework.com
https://www.guru99.com/test-driven-development.html
 THANK YOU

Team – Adaptive Software Engineering