New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

CSE 360 Week 5 (pt3)

by: Alexandra Notetaker

CSE 360 Week 5 (pt3) CSE 360

Alexandra Notetaker
GPA 3.5

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

These notes cover Requirements Engineering
Software Engineering
Debra Calliss
Class Notes
CSE360, Computer Science, software engineering, Lecture Notes, study
25 ?




Popular in Software Engineering

Popular in Computer Science and Engineering

This 5 page Class Notes was uploaded by Alexandra Notetaker on Thursday September 15, 2016. The Class Notes belongs to CSE 360 at Arizona State University taught by Debra Calliss in Fall 2016. Since its upload, it has received 2 views. For similar materials see Software Engineering in Computer Science and Engineering at Arizona State University.

Similar to CSE 360 at ASU

Popular in Computer Science and Engineering


Reviews for CSE 360 Week 5 (pt3)


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 09/15/16
CSE 360 REQUIREMENTS ENGINEERING  Requirements Engineering  Process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed  System requirements: descriptions of the system services and constraints that are generated during the requirements engineering process  Types of requirements  User Requirements:  Statements in natural language plus diagrams of the services the system provides and its operational constraints  System Requirements:  A structured document setting out detailed descriptions of the system’s functions, services, and operational constraints. Defines what should be implemented; so may be a part of a contract between client and contractor.  Functional Requirements  Describe functionality or system services  Depend on the type of software, expected users and the type of system where the software is used.  Functional user requirements:  May be high-level statements of what the system should do.  Functional System Requirements:  Should describe the system services in detail  Requirements: Completeness & consistency  Complete:  Include descriptions of all facilities requires  Consistent:  No conflicts in descriptions of system facilities  BUT  In practice, b/c system and environmental complexity it is impossible to produce complete and consistent required documents.  Non-Functional Requirements  Define system priorities and constraints (i.e. reliability, response time, ad storage requirements)  Process requirements may also mandate particular IDE, language, or development method.  May be more critical than functional—if not met, system = useless  Types of Non-Functional Requirements  How can you measure Non-Functional Requirements  Requirements Engineering Process  Widely dependent of application domain, people involved, and organization developing requirements:  Common processes:  Requirements elicitation  Requirements analysis  Requirements validation  Requirements management  In practice, (RE) is an iterative activity and processes are interleaved  Requirements Elicitation  Find application domain, services, performance, hardware, constraints, other systems, etc.  Stages:  Requirements discovery  Requirements classification and organization  Requirements Prioritization and Negotiation  Requirements Specification  Problems of Requirements Elicitation  Stakeholders don’t know what they want  Stakeholders express requirements in their own terms  Different stakeholders may have conflicting requirements  Organizational and political factors may influence requirements  New stakeholders may emerge and business environments change  Interviewing  Formal/informal interviews with stakeholders (RE) process  Types of interview:  Closed: pre-determined questions  Open: various issues explored  Effective interviewing  Open-minded: avoid pro-conceived ideas and listen  Prompt discussion:  Springboard question  Requirements proposal  Prototype system  Stories and scenarios = use cases  Real-life example of how they system can be used.  Stories/scenarios = description of how system may be used for a particular task  b/c they are based on practical solutions, stakeholders can relate to them, and can comment with respect to the story System Requirements Specification Representations  Guidelines for writing requirements  Use standard format for all requirements  Use language consistently  Shall = mandatory  Should = desirable  Use text highlighting key parts  Avoid computer jargon  Include explanation  Problems with Natural Language  Lack of clarity  Precision s difficult without making the document difficult to read  Requirements confusion  Functional/Non-Functional requirements get mixed up  Requirements Amalgamation  Several requirements expressed together  Software Requirements Document  Official statement of requirements for software developers  Include definition of user requirements and specification of the system requirements  NOT a design document  Sets what they system should do and how it should do it. User Requirements Document  Requirements Validation  Demonstrating that the requirements define customer needs  Requirements error costs = high  Validation is very important  Fixing requirement errors cost 100x the cost of fixing implementation error  Requirements Checks  Validity  Consistency  Completeness  Realism  Verifiability  Requirements Validation Techniques  Requirements Reviews:  Systematic manual analysis of requirements  Prototyping:  Using executable model of system to check requirements  Test case generation:  Developing tests for requirements to check testability  Requirements Reviews  Regular reviews help while requirements are formulated  Client and contractor staff involved  Formal/informal: good communication to resolve problems early  Review Check  Verifiability  Requirements realistically testable  Comprehensibility  Requirements understood  Traceability  Origin of requirement stated  Adaptability  Requirement can be changes without a large impact


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Bentley McCaw University of Florida

"I was shooting for a perfect 4.0 GPA this semester. Having StudySoup as a study aid was critical to helping me achieve my goal...and I nailed it!"

Allison Fischer University of Alabama

"I signed up to be an Elite Notetaker with 2 of my sorority sisters this semester. We just posted our notes weekly and were each making over $600 per month. I LOVE StudySoup!"

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.