Académique Documents
Professionnel Documents
Culture Documents
and
Design
Requirement
• Functional Requirements
• Non Functional Requirements (NFRs)
– Performance
– Security
– Logging
– Reliability
Characteristics of Good Requirements
• Correct
• Clear
• Understandable
• Unambiguous
• Testable (Verifiable)
• Feasible
• Independent
• Atomic
• Necessary
• Implementation-free
• Consistent
• Complete
• Non-redundant
Requirements
Engineering Tasks
The Problems with our Requirements Practices
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Inception Task
• During inception, the requirements engineer asks a set of questions to
establish…
– A 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
• Through these questions, the requirements engineer needs to…
– Identify the stakeholders
– Recognize multiple viewpoints
– Work toward collaboration
– Break the ice and initiate the communication
Questions Asked..
First Set of questions Next Set of Questions Final Set of questions
These questions focus on the These questions enable the These questions focus on
customer, other stakeholders, requirements engineer to gain a the effectiveness of the
the overall goals, and the better understanding of the communication activity itself
benefits problem and allow the customer to
voice his or her perceptions about
a solution
• Who is behind the request • How would you characterize • Are you the right person
for this work? "good" output that would be to answer these
• Who will use the solution? generated by a successful questions? Are your
• What will be the economic solution? answers "official"?
benefit of a successful • What problem(s) will this • Are my questions
solution? solution address? relevant to the problem
• Is there another source for • Can you show me (or describe) that you have?
the solution that you need? the business environment in • Am I asking too many
which the solution will be used? questions?
• Will special performance issues • Can anyone else provide
or constraints affect the way the additional information?
solution is approached? • Should I be asking you
anything else?
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Elicitation Task
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Elaboration Task
• During elaboration, the software engineer takes the information
obtained during inception and elicitation and begins to expand
and refine it
• Elaboration focuses on developing a refined technical model of
software functions, features, and constraints
• It is an analysis modeling task
– Use cases are developed
– Domain classes are identified along with their attributes and
relationships
– State machine diagrams are used to capture the life on an object
• The end result is an analysis model that defines the functional,
informational, and behavioral domains of the problem
Developing Use Cases
• Already Done
(Refer to Use Case diag slides)
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Negotiation Task
• During negotiation, the software engineer
reconciles the conflicts between what the
customer wants and what can be achieved
given limited business resources
• Requirements are ranked (i.e., prioritized)
by the customers, users, and other
stakeholders
• Risks associated with each requirement
are identified and analyzed
• Rough guesses of development effort are
made and used to assess the impact of
each requirement on project cost and
delivery time
• Using an iterative approach, requirements
are eliminated, combined and/or modified
so that each party achieves some measure
of satisfaction
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Specification Task
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Validation Task
• During validation, the work products produced as a result of requirements engineering are
assessed for quality
• The specification is examined to ensure that
– all software requirements have been stated unambiguously
– inconsistencies, omissions, and errors have been detected and corrected
– the work products conform to the standards established for the process, the project, and the product
• The formal technical review serves as the primary requirements validation mechanism
– Members include software engineers, customers, users, and other stakeholders
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house the system or
product?
• Is each requirement testable, once implemented?
– Approaches: Demonstration, actual test, analysis, or inspection
• Does the requirements model properly reflect the information, function, and behavior of the
system to be built?
• Has the requirements model been “partitioned” in a way that exposes progressively more
detailed information about the system?
Questions to ask when Validating Requirements
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements
Management
Requirements Management Task
• Structured analysis
– Considers data and the processes that transform the data as
separate entities
– Data is modeled in terms of only attributes and relationships (but no
operations)
– Processes are modeled to show the 1) input data, 2) the
transformation that occurs on that data, and 3) the resulting output
data
• Object-oriented analysis
– Focuses on the definition of classes and the manner in which they
collaborate with one another to fulfill customer requirements
Elements of the Analysis Model
Flow-oriented Modeling
Data Modeling
Scenario-based Flow-oriented
modeling modeling
Use case text
Data flow diagrams
Use case diagrams
Control-flow diagrams
Activity diagrams
Processing narratives
Swim lane diagrams
Class-based Behavioral
modeling modeling
Class diagrams
State diagrams
Analysis packages
Sequence diagrams
CRC models
Collaboration diagrams
Design Engineering
Purpose of Design
• Design is where customer requirements, business needs, and technical considerations all come
together in the formulation of a product or system
• The design model provides detail about the software data structures, architecture, interfaces,
and components
• The design model can be assessed for quality and be improved before code is generated and
tests are conducted
– Does the design contain errors, inconsistencies, or omissions?
– Are there better design alternatives?
– Can the design be implemented within the constraints, schedule, and cost that have been established?
• A designer must practice diversification and convergence
– The designer selects from design components, component solutions, and knowledge available through
catalogueses, textbooks, and experience
– The designer then chooses the elements from this collection that meet the requirements defined by
requirements engineering and analysis modeling
– Convergence occurs as alternatives are considered and rejected until one particular configuration of
components is chosen
• Software design is an iterative process through which requirements are translated into a
blueprint for constructing the software
– Design begins at a high level of abstraction that can be directly traced back to the data, functional, and
behavioral requirements
– As design iteration occurs, subsequent refinement leads to design representations at much lower levels
of abstraction
From Analysis Model to Design Model
• Each element of the analysis model provides information that is necessary
to create the four design models
– The data/class design transforms analysis classes into design classes along with
the data structures required to implement the software
– The architectural design defines the relationship between major structural
elements of the software; architectural styles and design patterns help achieve
the requirements defined for the system
– The interface design describes how the software communicates with systems
that interoperate with it and with humans that use it
– The component-level design transforms structural elements of the software
architecture into a procedural description of software components
From Analysis Model to
Design Model (continued)
Component-level Design
Interface Design
Architectural Design
Data/Class Design
"Writing a clever piece of code that works is one thing; designing something
that can support a long-lasting business is quite another."
Design Quality Guidelines
1) A design should exhibit an architecture that
a) Has been created using recognizable architectural styles or patterns
b) Is composed of components that exhibit good design characteristics
c) Can be implemented in an evolutionary fashion, thereby facilitating implementation and
testing
2) A design should be modular; that is, the software should be logically partitioned
into elements or subsystems
3) A design should contain distinct representations of data, architecture, interfaces,
and components
4) A design should lead to data structures that are appropriate for the classes to be
implemented and are drawn from recognizable data patterns
5) A design should lead to components that exhibit independent functional
characteristics
6) A design should lead to interfaces that reduce the complexity of connections
between components and with the external environment
7) A design should be derived using a repeatable method that is driven by
information obtained during software requirements analysis
8) A design should be represented using a notation that effectively communicates its
meaning
Design Concepts
Interface Design
Architectural Design
Data/Class Design
Dimensions of the Design Model
High
Analysis model
Abstraction Dimension
Design model
– Component-level design
• A fifth element that follows all of Interface Design
Data/Class Design
Design Elements
• Data/class design
– Creates a model of data and objects that is represented at a high level
of abstraction
• Architectural design
– Depicts the overall layout of the software
• Interface design
– Tells how information flows into and out of the system and how it is
communicated among the components defined as part of the
architecture
– Includes the user interface, external interfaces, and internal interfaces
• Component-level design elements
– Describes the internal detail of each software component by way of data
structure definitions, algorithms, and interface specifications
• Deployment-level design elements
– Indicates how software functionality and subsystems will be allocated
within the physical computing environment that will support the software