
















Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
This course includes types of requirements, modeling of non functional, static and dynamic modelling, requirement elicitation and use case modeling. This lecture includes: Examples, Processes, Software, Engineering, Development, Change, Management, Design
Typology: Slides
1 / 24
This page cannot be seen from the preview
Don't miss anything!

















1
Lecture # 5
2
A process is an organized set ofactivities, which transforms inputs tooutputs
-^
We can use synonyms of process suchas: procedure, method, course ofaction, etc.
-^
Processes are essential for dealingwith complexity in real world
4
-^
An instruction manual for operating amicrowave oven
-^
An instruction manual for assembling acomputer or its parts
-^
A procedure manual for operating a motorvehicle radio and CD player
5
A quality manual for softwaredevelopment.Such a manual describes theprocesses, which should be used toassure the quality of the software
7
Requires creativity
-^
Provides interactions between a widerange of different people
-^
Helps in engineering judgment
-^
Requires background knowledge
8
Software engineering developmentprocess (SDLC)
-^
Requirements engineering process
-^
Design process
-^
Quality assurance process
-^
Change management process
10
A process model is a simplifieddescription of a process presentedfrom a particular perspective
-^
There may be several different modelsof the same process
-^
No single model gives a completeunderstanding of the process beingmodeled
11
-^
A process model is produced on theanticipated need for that model. We mayneed–
A model to help explain how processinformation has been organized
-^
A model to help understand and improve aprocess
-^
A model to satisfy some quality managementstandard
13
This type of model provides an overallpicture of the process
-^
Describes the context of differentactivities in the process
-^
It doesn’t document how to enact aprocess
14
Software requirements follow the“system requirements” and “systemdesign”
-^
The primary goal is understanding
-^
Software requirements are followedby software design in a softwaredevelopment life cycle
16
System acquisition
Requirements engineering
System design
17
Requirements engineering process isan example of coarse-grain activitymodel
19
Informal statement of
requirements Draft requirements
document
Requirementsdocument andvalidation report
Agreed requirements
START
Requirementelicitation
Requirement analysis
and negotiation
Requirementvalidation
Requirementdocumentation
20
These are more detailed models of aspecific process, which are used forunderstanding and improving existingprocesses
-^
We’ll discuss some fine-grainprocesses within the generalrequirements engineering processes inlater lectures