Activity Communication

Action

Task Project Inception 1. May be performed via a project blastoff meeting to discover the following info:

Product purpose, Project sponsors, Clients, Users, Other stakeholders, Other sources of requirements, Constraints, Scope of the work, Relevant facts and assumptions and risk

Requirements Engineering

IEEE Standard Glossary of Software Engineering Terminology (IEEE, 1990):

A condition or capability needed by a user to solve a problem or achieve an objective. A condition or capability that must be met or possessed a system or system component to satisfy a contract, standard, specification or other formally imposed document. A documented representation of a condition or capability as in (1) and (2).

Types of Requirement Functional requirements (FR) IEEE Standard Glossary of Software Engineering Terminology (1990) define FR as:

a requirement that specifies a function that a system or system component must be able to perform

with function is defined as a defined objective or characteristic action of a system or component .

Non-functional requirements (NFR) A requirement that specifies quality characteristics/attributes of the software and constraints of the software to be developed and/or process to develop the software. Classifications of NFRs:

Product Organizational External Constraints Quality

What is RE? Sommerville & Sawyer (1997): a relatively new term which has been invented to cover all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system. The use of the term engineering implies that systematic and repeatable techniques should be used to ensure that systems are complete, consistent, relevant, etc .

Pohl (1996): the process of developing a requirements specification

Pressman (2009) as the broad spectrum of tasks and techniques that lead to an understanding of requirements

RE process: a structured set of activities which are followed to derive, validate and maintain a systems requirements document (Sommerville and Sawyer, 1997). Why RE is Important? 1. 2. 3. 4. RE process can influence the development cost, time, effort, and quality of the product. RE process is an essential contributor to the overall quality of the software product. Incomplete requirements and changing requirements are major causes of project failures. Good RE practices contribute more than 42% towards the overall success of a project, while improper RE practices account for more than 43% of the reasons why projects are late or over budget (CHAOS, 1995).

(5) Main Tasks in RE Process Requirement Elicitation 1. Critical task in RE to discover requirements from stakeholders . 2. 4 components of requirements elicitation:

Understanding application domain Understanding problem to be solved Understanding business processes in an organization Understanding the needs and constraints of the stakeholders 3. Work Product statement of need and feasibility. scope for the system or product. a list of customers, users, and other stakeholders description of the system s technical environment. list of requirements and the domain constraints that apply to each. set of usage scenarios any prototypes developed to better define requirements. 4. Problems Encountered According to Christel and Kang (1992); Problems of scope Problems of volatility Problems of Understanding Techniques of Elicitation

5.

Traditional

Modern

1. Interviews 2. Questionnaires and Surveys 3. Observations 4. Analysis of Archival Document 5. External Research
Requirement Analysis & Negotiation 1. Build analysis model (or requirements model)*

6. Iterative Prototyping 7. Joint Application Design (JAD) 8. Rapid Application Development (RAD) 9. Quality Function Deployment (QFD)*

Generic elements common to most requirements models:

2. 3. 4. 5.

Scenario-based elements processing narrative of software function Class-based elements implied by scenario Behavioral elements State Diagram Flow-oriented elements - DFD

Prioritizing Requirements Conflict and conflict resolution Negotiating requirements Assessing requirements risk

Techniques Prioritization scale - E.g.: MoSCoW method (Coley Consulting, 2008)

QFD Semi-quantitative Analytical Approach

Requirement Specification

To build the requirements document: SRS (software requirements specification) An official document that consists of information that should guide the system developers such as designers, programmers, and engineers through the development work of the product. Should involve technical writers

appropriate skills for gathering requirements, reviewing historic reports, writing formal documents and reports, and etc. can better assess and plan documentation tasks. know how to determine the questions that are of concern to the customers and users regarding non-functional requirements like ease of use and usability

Requirement Verification and Validation Sommerville (2007):

Requirements verification is a process of checking that a product meets its specification; and Requirements validation is a process of checking that a product meets the needs and expectations of the customer.

Techniques 1. Reviews the requirements specification 2. Prototyping 3. Acceptance Tests Verification A process for: y Ensuring that the requirements have been defined. y Determining that the requirements analysis has been correctly performed. y Determining that the requirements provide all the information needed to develop the solution. y Determining that the requirements are ready for formal review and validation by the customer and users. Validation A process for: y Determining whether the requirements are accurate, correctly align to the needs of the customer, and have appropriate level of detail. Focuses on: y Supporting business goals/objectives, Aligning with business goals/objectives, Meeting stakeholders needs.

y y

Focuses on quality: y Completeness, y Correctness, y Usability, etc. Requirement Management Ripple Effect one thing causes a series of other things to happen

Changes in requirements specified in a requirements document are inevitable and must be allowed.

Requirements management: 1. 2. 3. 4. Managing configuration of requirements and requirements document Maintaining requirements traceability Tracking requirements status Managing changes to requirement

Why Changes in Requirement Occur? Internal Factors External Factors

1. Failure to elicit the real requirements of the stakeholders. 2. Iterating from requirements to design creates new requirements. 3. The implementation team might encounter technical, schedule and/or cost problems in implementing a requirement. 4. RE process is iterative and must create a practical process to help manage changing requirements. Failure to create a practical requirements change management process will only cause rework and stress.

5. The problem we are trying to solve somehow change as a result of a changing economy, government regulations, consumer preferences etc. 6. Customers and users understand better what they really require from a system or simply change their minds. 7. The customers organization may change its structure, procedures and processes . 8. The external environment change, which create new constraints and opportunities.

Planning

Modeling

Requirements Modeling

A graphical representations of business processes, the problems to be solved, and the new proposed product (software).

Objectives: 1. 2. 3. To describe software requirements. To establish a basis for the creation of a software design. To define a set of requirements that can be validated once the software is built.

Bridges the gap between a software specification and a software design.

Rules of Thumb Suggested by Arlow and Neustadt in Pressman (2009):

The model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system. Delay consideration of infrastructure and other non-functional models until design. Minimize coupling throughout the system. Be sure that the analysis model provides value to all stakeholders. Keep the model as simple as possible

Requirements Principle #1. The information domain of a problem must be represented and understood.

Principle #2. The functions that the software performs must be defined. Principle #3. The behavior of the software (as a consequence of external events) must be represented. Principle #4. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion. Principle #5. The analysis task should move from essential information toward implementation detail.

Domain Analysis

An on-going SE activity that is not connected to any software project (by domain analyst) Involves: 1. 2. 3. 4. Defining the domain to be investigated. Collecting a representative sample of applications in the domain. Analyzing each application in the sample. Developing an analysis model for the objects.

Requirement Analysis Model

Categorized into two main levels of details: 1. Context (conceptual-level) modeling*

2.

High-level conceptual descriptions of a product and its environment. Must be supplemented with detailed-level models Usually usable to non-technical people and decision-makers

Technical (detailed-level) modeling

Approach for Technical Modelling 1. 2. Structured Analysis Object-oriented Analysis

Need to first understand OO concepts, which include objects, classes, attributes, methods, sub-class, super-class, and etc. Classifications of OO modeling elements (Pressman, 2005): 1. Scenario-based

Sce

io- se Mo eli : Use

se

Iv

co so :
     

[Use-c ses] c ses

e si

ly

o efi i

e is s o si e
   

e sys e


cos


s o l


e e fo


e sys e


se -

Ele e s:


y y
#

Ac o


Use c se
$ $ & & ! % ' % " (

Sce

io- se Mo eli : Ac ivi y i

1 #

"

le e s
& ( !

e se c se y
)

ovi i

ic l e ese
" 0 "

io of
!

e flo of inte
2

tion ithin spe ifi s en io .

4 5 5 5 4 2 3

&

&

&

&

"

"

y bol
7

Pu pose
8

To e ese
9 @ 9

c ivi y
B B

To e ese
9 @ 9

flo
E 9 C A

To e ese
9 @ 9

c i
F C

ecisio s
A

To i

ic e ll
B C C

llel c ivi ies i i

F B B B C D

e sys e .
B I

Sce

io- se Mo eli : S i l e i
S T T Q P U V W Q P X Y Y Q R Q P Y

A v i io of ac ivi y diagram. To re rese the flo of activities descri ed by the use -case and at the same time indicate which actor (if there are multi le actors involved in a s ecific use-case or analysis class has res onsibility for the action described by an activity rectangle.
` P Y V ` a ` ` S

2.

Class-based

Class-based Modeling: Class Diagram

Depicts a collection of system s classes, their attributes, and the relationships between the classes. To model a class, use a rectangle with three sections: 1. 2. 3. name of the class (top) list of attributes (middle) methods (bottom).

Two basic types of relationships between classes: 1. 1. Associations Inheritance/generalisation

Class-based Modeling: CRC

Wir (1990): CRC modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. Ambler (1995): A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections. Along the top of the card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right.

3.

Behavioral

Make a list of the different states of a system Indicate how the system makes a transition from one state to another

indicate event indicate action

Draw a state diagram

State of a system State a set of observable circum-stances that characterizes the behavior of a system at a given time State transition the movement from one state to another Event an occurrence that causes the system to exhibit some predictable form of behavior Action process that occurs as a consequence of making a transition State Representation In the context of behavioral modeling, two different characterizations of states must be considered The state of a class takes on both passive and active characteristics

Behavioral Modeling: Sequence Diagram An interaction diagram that details how operations are carried out Are organized according to time.

Construction Deployment