Lecture

Requirements: User Stories

Graph Chat

Chat with Graph Search

Ask any question about EPFL courses, lectures, exercises, research, news, etc. or try the example questions below.

DISCLAIMER: The Graph Chatbot is not programmed to provide explicit or categorical answers to your questions. Rather, it transforms your questions into API requests that are distributed across the various IT services officially administered by EPFL. Its purpose is solely to collect and recommend relevant references to content that you can explore to help you answer your questions.

In course

CS-305: Software engineering

This course teaches the basics of modern software development: designing software, working in a team, writing good code, shipping software, and evolving software. It emphasizes building software that meets high standards of quality, reliability, security, ...

Description

This lecture covers the definition of requirements, emphasizing the importance of user input in eliciting requirements, developing user stories, and formalizing them using BDD. It also discusses the process of tying tests to implementation and validating requirements.

Instructor

George Candea

George Candea heads the Dependable Systems Lab, where he develops techniques and abstractions for building efficient and trustworthy computer systems. His current work focuses on making performance and energy programmable, i.e., providing first-class abstractions to capture a system’s performance and energy behavior (as interfaces do for functionality) and to use them dependably to design, code, and operate efficient systems.In the recent past, George also served as CEO and later Chief Scientist of Cyberhav

Official source

Ontological neighbourhood

Systems science and engineering

Systems thinking: Systems engineering

Related concepts (18)

Non-functional requirement

In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.

Requirement

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary (or sometimes desired) function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder.

Requirements analysis

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements. Requirements analysis is critical to the success or failure of a systems or software project.cite book |editor1= Alain Abran |editor2=James W.

Requirements engineering

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering. The first use of the term requirements engineering was probably in 1964 in the conference paper "Maintenance, Maintainability, and System Requirements Engineering", but it did not come into general use until the late 1990s with the publication of an IEEE Computer Society tutorial in March 1997 and the establishment of a conference series on requirements engineering that has evolved into the International Requirements Engineering Conference.

Business requirements

Business requirements, also known as stakeholder requirements specifications (StRS), describe the characteristics of a proposed system from the viewpoint of the system's end user like a CONOPS. Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements. Consequently, business requirements are often discussed in the context of developing or procuring software or other systems. Three main reasons for such discussions: A common practice is to refer to objectives, or expected benefits, as 'business requirements.

Related lectures (63)

Requirements Definition

Explores the fundamentals of requirements definition in systems engineering, emphasizing the importance of clear and concise requirements for successful system design.

Systems Engineering: Requirements, Architecture, and Standards

Explores the history, definitions, and challenges of Systems Engineering, emphasizing the importance of requirements in system design and architecture.

From Tests to Proof

Explores software engineering concepts, emphasizing the significance of tests and clear specifications in ensuring software correctness.

Systems Engineering: Introduction and Stakeholders

Introduces Systems Engineering, emphasizing stakeholder analysis and clear requirement definition for project success.

Scenarios and Requirements