meljun cortes analysis concepts and principles
DESCRIPTION
MELJUN CORTES Analysis concepts and principles----->THESIS writing model techniques on how to prepare DFD.TRANSCRIPT
Requirements Requirements AnalysisAnalysis
Analysis as a bridge between system engineering and software design
MELJUN CORTESMELJUN CORTES
Requirements Requirements ElicitationElicitation
Analysis Concepts and Principles
Requirements ElicitationRequirements ElicitationBefore requirements can be
analyzed, modeled, or specified they must be gathered through an elicitation process. A customer has a problem that may be amenable to a computer-based solution. A developer responds to the customer's request for help. Communication has begun.
Initiating The Initiating The ProcessProcess
Requirements Elicitation
Initiating the ProcessInitiating the ProcessThe most commonly used
requirements elicitation technique is to conduct a meeting or interview.
◦Analyst should first start by asking context-free questions. That is, a set of questions that will lead to a basic understanding of the problem, the people who want a solution, the nature of the solution that is desired, and the effectiveness of the first encounter itself. (Gause and Weinberg)
Initiating the ProcessInitiating the ProcessThe first set of context-free
questions focuses on the customer, the overall goals, and the benefits.
Initiating the ProcessInitiating the ProcessThe next set of questions enables
the analyst to gain a better understanding of the problem and the customer to voice his or her perceptions about a solution.
Initiating the ProcessInitiating the ProcessThe final set of questions focuses
on the effectiveness of the meeting.
◦Meta-questions. (Gause and Weinberg)
Facilitated Facilitated Application Application Specification Specification TechniquesTechniques
Requirements Elicitation
Facilitated Application Facilitated Application Specification TechniquesSpecification TechniquesA number of independent
investigators have developed a team-oriented approach to requirements gathering that is applied during early stages of analysis and specification.
Facilitated Application Facilitated Application Specification TechniquesSpecification TechniquesFacilitated Application Specification
Techniques (FAST), this approach encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of the solution, negotiate different approaches and specify a preliminary set of solution requirements
Basic GuidelinesBasic GuidelinesFacilitated Application Specification Techniques
Basic GuidelinesBasic GuidelinesArrange a meeting at a neutral
site for developers and customers.
Establishment of rules for preparation and participation.
Prepare and informal agenda that encourages free flow of ideas.
Basic GuidelinesBasic GuidelinesAppoint a facilitator – can be a
customer, a developer, or an outside expert – to control the meeting.
Prepare a definition mechanism – Board, Flip Charts, Worksheets, Wall Stickers, Etc.
Participants should not criticize or debate.
Activities Of FAST Activities Of FAST SessionSession
Facilitated Application Specification Techniques
Activities of FAST SessionActivities of FAST SessionEach participants presents their
list of objects, services, constraints, and performance for discussion. List may be displayed in the meeting using board, or any other mechanism, so that it will be visible to all the participants.
Activities of FAST SessionActivities of FAST SessionThe combined list for each topic
are prepared by eliminating redundant entries and adding new ideas.
The combined lists are again discussed and consensus lists are finalized by the facilitator.
Activities of FAST SessionActivities of FAST SessionOnce the consensus lists have
been completed, the team is divided into smaller sub teams, each works to develop mini-specifications for one or more entries of the lists.
Activities of FAST SessionActivities of FAST SessionEach sub team then presents
mini-specification to all FAST attendees. After discussion, additions or deletions are made to the lists. We may get new objects, services, constraints, or performance requirements to be added to original lists.
Activities of FAST SessionActivities of FAST SessionDuring all discussion, the team
may raise an issue that cannot be resolved during the meeting. An issue list is prepared so that these ideas will be considered later.
Activities of FAST SessionActivities of FAST SessionEach attendee prepares a list of
validation criteria for the product/system and presents the list to the team. A consensus list of validation criteria is then created.
A sub team may be asked to write the complete draft specifications using all inputs from the FAST meeting.
Quality Function Quality Function DeploymentDeployment
Requirements Elicitation
Quality Function Quality Function DeploymentDeploymentQuality function deployment (QFD) is a
quality management technique that translates the needs of the customer into technical requirements for software. QFD “concentrates on maximizing customer satisfaction from the software engineering process.”
To accomplish this, QFD emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process.
Quality Function Quality Function Deployment Types Of Deployment Types Of RequirementsRequirements
Quality Function Deployment
QFD Types of QFD Types of RequirementsRequirementsNormal Requirements
◦The objectives and goals that are stated for a product or system during meetings with the customer. If these requirements are present, the customer is satisfied.
QFD Types of QFD Types of RequirementsRequirementsExpected Requirements
◦These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. Their absence will be a cause for significant dissatisfaction.
QFD Types of QFD Types of RequirementsRequirementsExciting Requirements
◦These features go beyond the customer’s expectations and prove to be very satisfying when present. For example, word processing software is requested with standard features. The delivered product contains a number of page layout capabilities that are quite pleasing and unexpected.
Use - CasesUse - CasesRequirements Elicitation
Use-CaseUse-CaseUse cases are a software
modeling technique that helps developers to determine which features to implement and how to resolve errors gracefully.
Use-CaseUse-CaseTo create a use-case
◦The analyst must first identify the different types of people (or devices) that use the system or product.
◦Create a user profile for each category of users, including all the roles the users play.
Use-CaseUse-CaseTo create a use-case
◦Create a use-case for each goal – following the use-case template.
◦Structure the use-cases. Avoid over-structuring.
◦Review and validate with users.
Use-CaseUse-Case
Use - Case Template
1 Brief Description
2 Actors
3 Pre - condition
4 Post - condition
5 Flow of Events
6 Special Requirements
7 Related Use Cases
Use-CaseUse-Case
Use - Case Template
1 Brief Description
2 Actors
3 Pre - condition
4 Post - condition
5 Flow of Events
6 Special Requirements
7 Related Use Cases
Actors
◦ Represent roles that people (or devices) play as the system operates.
◦ Also anything that communicates with the system or product and that is external to the system itself.
Use-CaseUse-Case
Use - Case Template
1 Brief Description
2 Actors
3 Pre - condition
4 Post - condition
5 Flow of Events
6 Special Requirements
7 Related Use Cases
Flow of Events
◦ Basic Flow
◦ Alternative Flow
Use-Case
Restaurant Use Case Model
Analysis PrinciplesAnalysis PrinciplesAnalysis Concepts and Principles
Analysis PrinciplesAnalysis PrinciplesThe Information domain of a
problem must be represented and understood.
The functions that the software is to perform must be defined.
The behavior of the software must be represented.
Analysis PrinciplesAnalysis PrinciplesThe models that depict
information, function and behavior must be partitioned in a manner that uncovers detail in a layered fashion.
The analysis process should move from essential information toward implementation details.
Information DomainInformation DomainAnalysis Principles
Information DomainInformation DomainThe information domain contains
three different views of the data and control.
◦Information content and relationships.
Information DomainInformation DomainThe information domain contains
three different views of the data and control.
◦Information content and relationships.
◦Information flow.
Information DomainInformation DomainInformation Flow
Information DomainInformation DomainThe information domain contains
three different views of the data and control.
◦Information content and relationships.
◦Information flow.
◦Information structure.
ModelingModelingAnalysis Principles
ModelingModelingPhysical (a building, a plane, a
machine)◦We can build a model that is identical in
form and shape but smaller in scale.
Software◦It must be capable of representing the
information that software transforms, the functions (and sub functions) that enable the transformation to occur, and the behavior of the system as the transformation is taking place.
Types Of ModelingTypes Of ModelingModeling
Types of ModelingTypes of ModelingFunctional Models
◦Software transforms information, and in order to accomplish this, it must perform at least three generic functions: input, processing, and output.
Types of ModelingTypes of ModelingBehavioral Models
◦Most software responds to events from the outside world. This stimulus/response characteristic forms the basis of the behavioral model.
PartitioningPartitioningAnalysis Principles
PartitioningPartitioningProblems are often too large and
complex to be understood as a whole.
For this reason, partitioning (dividing) such problems into parts that can be easily understood and establish interfaces between the parts so that overall function can be accomplished.
PartitioningPartitioning
Exposing increasing detail by moving vertically in the hierarchy
SafeHome Software
PartitioningPartitioning
SafeHome Software
Configure System
Exposing increasing detail by moving vertically in the hierarchy
PartitioningPartitioning
SafeHome Software
Monitor Sensors
Configure System
Exposing increasing detail by moving vertically in the hierarchy
PartitioningPartitioning
SafeHome Software
Monitor Sensors
Configure System
Exposing increasing detail by moving vertically in the hierarchy
PartitioningPartitioning
SafeHome Software
Monitor Sensors
Configure System
Poll for Sensor Event
Exposing increasing detail by moving vertically in the hierarchy
PartitioningPartitioning
SafeHome Software
Monitor Sensors
Configure System
Poll for Sensor Event
Activate Alarm
Function
Exposing increasing detail by moving vertically in the hierarchy
PartitioningPartitioning
SafeHome Software
Monitor Sensors
Configure System
Interact With User
Poll for Sensor Event
Activate Alarm
Function
Exposing increasing detail by moving vertically in the hierarchy
PartitioningPartitioning
Functionally decomposing the problem by moving horizontally in the hierarchy.
SafeHome Software
PartitioningPartitioning
Functionally decomposing the problem by moving horizontally in the hierarchy.
SafeHome Software
Configure System
PartitioningPartitioning
Functionally decomposing the problem by moving horizontally in the hierarchy.
SafeHome Software
Monitor Sensors
Configure System
PartitioningPartitioning
Functionally decomposing the problem by moving horizontally in the hierarchy.
SafeHome Software
Monitor Sensors
Configure System
Interact with User
PartitioningPartitioning
SafeHome Software
Monitor Sensors
Configure System
Interact with User
Poll for Sensor Event
Functionally decomposing the problem by moving horizontally in the hierarchy.
PartitioningPartitioning
SafeHome Software
Monitor Sensors
Configure System
Interact with User
Poll for Sensor Event
Activate Alarm
Function
Functionally decomposing the problem by moving horizontally in the hierarchy.
Essential ViewEssential ViewAnalysis Concepts and Principles
LogicalLogicalEssential View
Implementation ViewImplementation ViewAnalysis Concepts and Principles
PhysicalPhysicalImplementation View
Software PrototypingSoftware PrototypingAnalysis Concepts and Principles
Software PrototypingSoftware PrototypingPrototyping is the rapid
development of a system.
Rapid software development to validate requirements.
Software PrototypingSoftware PrototypingThe principal use is to help
customers and developers understand the requirements for the system.
◦Requirements elicitation – Users can experiment with a prototype to see how the system supports their work.
◦Requirements validation – The prototype can reveal errors and omissions in the requirements.
Prototyping Prototyping ApproachApproach
Software Prototyping
Prototyping ApproachPrototyping ApproachThe prototyping paradigm can be
either close-ended or open-ended.
◦The close-ended approach is often called throwaway prototyping. Using this approach, a prototype serves solely as a rough demonstration of requirements. It is then discarded, and the software is engineered using a different paradigm.
Prototyping ApproachPrototyping ApproachThe prototyping paradigm can be
either close-ended or open-ended.
◦An open-ended approach, called evolutionary prototyping, uses the prototype as the first part of an analysis activity that will be continued into design and construction.
Prototyping Methods Prototyping Methods And ToolsAnd Tools
Software Prototyping
Prototyping Methods and Prototyping Methods and ToolsToolsFourth Generation Techniques
◦4GT encompass a broad array of database query and reporting languagfes, program and application generators, and other very high-level nonprocedural languages. Because 4GT enable the software engineer to generate executable code quickly, they are ideal for rapid prototyping.
Prototyping Methods and Prototyping Methods and ToolsToolsReusable Software Components
◦Another approach to rapid prototyping is to assemble, rather than build, the prototype by using a set of existing software components. It should be noted that an existing software product can be used as a prototype for a "new, improved" competitive product. In a way, this is a form of reusability for software prototyping.
Prototyping Methods and Prototyping Methods and ToolsToolsFormal Specification and
Prototyping Environments
◦Over the past two decades, a number of formal specification languages and tools have been developed as a replacement for natural language specification techniques.
Prototyping Methods and Prototyping Methods and ToolsToolsFormal Specification and Prototyping
Environments
◦Today, developers of the formal languages are in the process of developing interactive environments that
Enable an analyst to interactively create language-based specifications of a system or software,
Invoke automated tools that translate the language-based specifications into executable code, and
Enable the customer to use the prototype executable code to refine fomral requirements.
Specification Specification PrinciplesPrinciples
Specification
Specification PrinciplesSpecification PrinciplesSeparate functionality from
implementation.
Develop a model of the desired behavior of a system.
Establish the background in which software operates.
Define the environment established.
Specification PrinciplesSpecification PrinciplesCreate a cognitive model rather than a
design or implementation model.
Recognize that “the specifications must be tolerant of incompleteness and augmentable.” A specification is always a model—an abstraction—of some real (or envisioned) situation that is normally quite complex. Hence, it will be incomplete and will exist at many levels of detail.
Establish the content and structure of a specification in a way that will enable it to be amenable to change.
Specification ReviewSpecification ReviewAnalysis Concepts and Principles
Specification ReviewSpecification ReviewA review of the Software
Requirements Specification (and/or prototype) is conducted by both the software developer and the customer. Because the specification forms the foundation of the development phase, extreme care should be taken in conducting the review.