February 21 - Requirements Engineering – Lecture Notes

 

8-9am:     presentations for Assignment #1

                feedback from Dr Barber

 

9-

Eliciting Requirements Lecture

1:  This weekend’s lecture will focus on the text documentation of modeling acquired requirements

2:  Scope defined by HOW, WHO, WHAT (as-is, to-be)

4:  This picture should be used as an opportunity for the team to determine WHO really needs to be interviewed

6:  Organizational viewpoint may not always be necessary

7:  Merging is based on organized domain viewpoints (or organizational)

-          when conflicting requirements are resolved, the process for resolving those conflicts should be well-documented (easier with graphical, not textual) as “iterations” of the unified requirements models (RMs)

8:  Based on existing computational model

 

Scenarios: Bounding and Defining the Problem Space

-          a scenario is just a storyline of what’s going on in the system

-          domain, environmental, technology (3 types of requirements – domain, non-functional, installation)

-          mental model – highest level model for the problem domain

o        takes time

o        bounded by initiating and terminating events

o        all-encompassing (nothing outside of this model)

 

Requirements Acquisition Strategy

 

Requirements from Session Type

 

Interview