cs 426 senior projects n.
Skip this Video
Loading SlideShow in 5 Seconds..
CS 426 Senior Projects PowerPoint Presentation
Download Presentation
CS 426 Senior Projects

Loading in 2 Seconds...

play fullscreen
1 / 16

CS 426 Senior Projects - PowerPoint PPT Presentation

  • Uploaded on

CS 426 Senior Projects. Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 26, 2011. Outline. The requirements workflow Metamodel for software requirements Requirements workflow details The importance of requirements Defining requirements. The Requirements Workflow.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'CS 426 Senior Projects' - gittel

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
cs 426 senior projects
CS 426Senior Projects

Chapter 3: The Requirements Workflow

[Arlow & Neustadt, 2005]

January 26, 2011

  • The requirements workflow
  • Metamodel for software requirements
  • Requirements workflow details
  • The importance of requirements
  • Defining requirements
the requirements workflow
The Requirements Workflow.

Fig. 3.2 [Arlow & Neustadt 2005] shows that most of the work

in requirements workflow occurs in Inception and Elaboration phases

the requirements workflow1
.The Requirements Workflow
  • The purpose of the requirements workflow is to reach an agreement on what the system should do, expressed in a way accessible to the users of the system
  • Requirements engineering involves: elicitation, negotiation, conflict resolution, prioritization, documentation, and maintenance of requirements
  • Various stakeholders are involved in establishing the set of requirements for the system
  • UML uses cases describe functional requirements, but non-functional requirements need different description
metamodel for software requirements
Metamodel for Software Requirements

Arlow & Neustadt’s approach for requirements engineering is shown in

Fig. 3.3 [Arlow 2002]. Details can be found in Section 3.3

requirements workflow detail
Requirements Workflow Detail.

Specific tasks for UP (Unified Process) requirements workflow

Fig. 3.4 [Arlow & Neustadt 2005]

requirements workflow detail1
.Requirements Workflow Detail

Arlow and Neustadt extend slightly the UP requirements workflow with

the addition of new tasks: find functional requirements, find non-

functional requirements, prioritize requirements, &trace requirements

to use cases. As such, non-functional requirements can be addressed

as well, along with the traditional UP/UML treatment of functional

requirements via use cases. Fig. 3.5 [Arlow & Neustadt 2005]

the importance of requirements
The Importance of Requirements
  • Requirements engineering is about establishing whatthe stakeholders need from the system
  • Requirements engineering encompasses elicitation, negotiation, conflict resolution, prioritization, documentation, and maintenance of requirements
  • Poor requirements engineering is the major cause of software project failure
  • The second major cause of software project failure is lack of user participation
defining requirements
Defining Requirements.…
  • Requirement: “a specification of what should be implemented”
  • There are two types of requirements:
    • Functional requirements: describe the desired behaviour of the system
    • Non-functional requirements: specify particular properties of or constraints on the system
  • In theory, the set of requirements should be only about “what” the system should do, but in practice it is not possible to avoid “how” aspects of the system
defining requirements1
.Defining Requirements...
  • The SRS (Systems Requirements Specification) is the document that contains the set of requirements expected to be satisfied by the system, both functional and non-functional
  • There are many ways to write an SRS (“company dependent” ways)
  • The SRS provides the input for the analysis and design phases of the development process
  • The bottom line regarding the SRS is: “does it help me to understand what the system should do or not?”
defining requirements2
..Defining Requirements..
  • Simple format recommended for well-formed requirements:

<id> The <system> shall <function>

  • Examples of functional requirements (what the system should do):

1 The ATM shall check the validity of the ATM card inserted.

2 The ATM shall validate the PIN number entered by the client.

3 The ATM shall dispense no more than $500 against any ATM card in any 24-hour period

  • Examples of non-functional requirements (constraints on or properties of the system):

1 The ATM shall be written in C++.

2 The ATM shall validate the PIN in three seconds or less.

defining requirements3
…Defining Requirements.
  • Organizing requirements: a more complex taxonomy can be used when there are many requirements, e.g.
    • Functional requirements
      • Customers
      • Products
      • Orders
      • Sales channels
      • Payments
    • Non-functional requirements:
      • Performance
      • Capacity
      • Availability
      • Compliance with standards
      • Security
defining requirements4
….Defining Requirements
  • Requirements may have attributes, e.g.
    • Must have
    • Should have
    • Could have
    • Want to have [the MoSCoW system]
  • Requirement attributes in RUP:
    • Status (proposed, approved, rejected, incorporated)
    • Benefit (critical, important, useful)
    • Effort (measured in person*day or function points)
    • Risk (high, medium, low)
    • Stability (high, medium, low)
    • TargetRelease (product version when implemented)
finding requirements
Finding Requirements..
  • Requirements come from the context of the system:
    • Direct users
    • Other stakeholders (e.g., managers, maintainers, installers)
    • Other systems that interact with the system
    • Hardware devices attached to the system
    • Legal and regulatory constraints
    • Technical constraints
    • Business goals
finding requirements1
.Finding Requirements
  • “The map is not the territory” (that is, a model is not the real thing). When modeling, we apply three cognitive filters that simplify our effort [Chomsky, 1975]:
    • Deletion (information is filtered out)
    • Distortion (information is modified)
    • Generalization (information is abstracted into rules, principles, etc)
  • In requirements specification we need to identify the application of the above filters and find “challenges” for them to recover information
  • In particular, universal quantifiers such as all, everyone, always, never, nobody, none should be inspected closely for accuracy
finding requirements2
..Finding Requirements
  • Interviews:
    • Don’t imagine a solution
    • Don’t mind read
    • Ask context-free questions
    • Listen
    • Have patience!
  • Questionnaire: they can supplement interviews.
    • Good at getting answers to closed questions
  • Requirements workshop
    • Participants: facilitator, requirements engineer, stakeholders, domain experts
    • Procedure: 1 Brainstorm (accept all ideas) 2 Identify key requirements 3 Iterate over, refine, and prioritize requirements