Si397 - S9 - Mad - Requirements Specification PDF

< / >
< / >
< / >
< / >
< / >
< / >
REQUIREMENTS SPECIFICATIOn
Material producido por la Universidad Peruana de Ciencias Aplicadas

UPC, 2021.
REQUIREMENTS SPECIFICATION
CONTENIDO
Objetivo de aprendizaje 3
Use cases 3
User stories 6
Epics 9
Themes 11
Backlog 12
Agile producto roadmap 14
Impact map 15
Conclusiones 16
Referencias 16
Material producido por la Universidad Peruana de Ciencias Aplicadas. UPC, 2021. 2

1. Objetivo de aprendizaje
Al finalizar la unidad de aprendizaje, el estudiante planifica experimentos para validar

requisitos de software especificados, aplicando métodos y frameworks de actualidad
para procesos de software.
2. USE CASES
Un caso de uso describe la funcionalidad pero también debe

describir un resultado.
!
Los casos de uso proporcionan “valor para uno o más actores

u otras partes interesadas del sistema".
Un modelo de CU está compuesto por dos partes:
Un diagrama (gráfico)
Una parte textual llamada Use Case Specification
El diagrama muestra las relaciones entre actores y casos de uso, así como las relaciones
entre los CU y entre actores (en caso existan).
La use case specification muestra la descripción escrita en lenguaje natural que narra los
pasos y demás características del caso de uso.
2.1. USE CASE SPECIFICATION
Se refiere a la descripción de cada una de las partes definidas para lograr su descripción completa del
use case. Partes básicas para su redacción:
USE CASE SPECIFICATION - NOMBRE

WEB DEVELOPING
BRIEF DESCRIPTION
Principal: Y [L
Actors
Secondary: /
Y [L
Flow of Basic flow:

events Alternative flows:

Parte 1
A good brief description Actor choices: one chosen for

aids readability the main/basic flow
Use – Case Specification – Register for Courses
Brief Description
This use case allows a student to register for course offerings in the current semester. The student
can also modify or delete course selections if changes are made with the add/drop period at the
beginning of the semester. The Course Catalog System provides a list of all the course offerings for
the current semester.
Actors
• Primary Actor – Student
• Secondary Actor – Course Catalog System
Flow of Events:
1. Basic Flow:
1.1. LOG ON
This use case starts when a student accesses the Course Registration System. The student enters a
student ID and password and the system validates the student.
1.2. CREATE SCHEDULE

The system displays the functions avaliable to the studente. These functions are: Create a Schedule,
Modify a Schedule and Delete a Schedule. The student selects “Create a Schedule”.
1.3. SELECT COURSES

The system retrieves a list of available course offerings from the Course Catalog System and displays
the list to the student. The Student selects up to 4 primary course offerings and 2 alternate course
offerings from the list of available offerings. The student can add and delete courses as desired until
choosing to submit the Schedule.
1.4. SUBMIT SCHEDULE

The student indicates that the schedule is complete. The system validates the courses selected
and displays the Schedule to the student. The system displays the confirmation number for the
Schedule. The systems saves the student’s Schedule information. The use case ends.
No references in the Steps have short

main flow names

Parte 2
What caused
the flow to What the
Reference at system does Where the flow
start
start of flow resumes
2. Alternative Flows
2.1. MODIFY A SCHEDULE

At basic flow step CREATE SCHEDULE, the student already has a Schedule that has been saved, the system retrieves and
displays the student’s current Schedule (e.g the Schedule for the current semester) and allows him/her to use it as a starting
point. The use case resumes at basic flow step SELECT COURSES.
2.2 DELETE A SCHEDULE

At basic flow step CREATE SCHEDULE the student has an existing Schedule and chooses to delete it. The system retrieves
and displays the student current Schedule. The system prompts the student to verify the deletion. The student verifies the
deletion. The system deletes the Schedule. The use case ends.
2.3 DELETE A SUBMITTED SCHEDULE

At alternative flow DELETE A SCHEDULE the students schedulle has ready been submitted Will incur 10% processing fee. The
student confirms the deletion. The system notifies the accounting system that the Schedule was deleted. The use case ends.
2.4. UNIDENTIFIED STUDENT

At basic flow step LOG ON, the system detemines that the student is not valid, an error message is displayed and the use
case ends.
2.5. QUIT
The Course Registration System allows the student to quit at any time during the use case. The student chooses not to save
any partial Schedule information. The use case ends.
2.6. QUIT AND SAVE

The student chooses to quit creating a Schedule and chooses to save a partial schedule before quitting. All courses that are
not marked as ‘’enrolled in’’ are marked as ‘’selected’’ in the Schedule. The system saves the Schedule. The use case ends.
2.7. CANNOT ENROL

At basic flow step SUBMIT SCHEDULE the system determines that prerequisites for a selected course are not satisfied, or
that the course is full, or that there are schedule conflicts, the system will not enrol the student in the course. The system
displays a message the student and the use case continues t basic flow step SELECT COURSES.
2.8. COURSE CATALOG UNAVAILABLE

At basic flow step SELECT COURSES, the system determines that the Course Catalog system is not available. The system
displays an error message and the use case ends.
2.9. REGISTRATION CLOSED

At basic flow step LOG ON, the system determines that registration is closed, the system indicates that student can no longer
select courses and the use case ends.
Flows have names
References use names,

An alternative flow can start in not numbers
another alternative flow

3. USER STORIES
As a « role»
I want « goal» La user story (historia de usuario) es una unidad de
So that « benefit» trabajo que representa algún valor para un usuario
Acceptance criteria: final y se puede entregar durante un sprint.
(Conditions of Satisfaction)
3.1. ASPECTOS
• Un user story describe la funcionalidad que será valiosa para un usuario o comprador
de un sistema o software.
• Los user stories se componen de tres aspectos:
Conversaciones sobre
la historia que sirven
para dar cuerpo a los
detalles de la historia.
Tests que evidencian y

Una descripción escrita
documentan detalles y
de la historia utilizada
que se pueden utilizar
para la planificación y
para determinar cuando
como recordatorio.
se completa una historia.
3.2. FORMATO
El formato de la descripción de un user story es simple y breve:
Como [tipo de usuario]
Quiero [una acción]
Para que [un beneficio / un valor]

Ejemplo 1
Descripciones de user stories que se ajustan a un proyecto de aplicación de taxi dentro de sus
requisitos funcionales:
• Como conductor, quiero bloquear a los pasajeros

con mal comportamiento para evitar su
incorporación al grupo de clientes vip.
• Como pasajero, quiero vincular la tarjeta de

crédito a mi perfil para pagar un viaje de forma
rápida, fácil y sin efectivo.
• Como conductor, quiero agregar fotos de mi

automóvil en mi perfil para atraer a los usuarios.
• Como pasajero, quiero saber quiénes son los

conductores disponibles de manera que puedo
elegir la opción más adecuada para mí.
Ejemplo 2
Descripciones de user stories que se ajustan a un proyecto de aplicación de taxi dentro de sus
requisitos no funcionales:
• Como usuario, quiero ejecutar la app en el

sistema operativo Android para acceder desde
cualquier lugar a través de mi dispositivo móvil.
• Como conductor, quiero que la app esté

disponible el 99.999 por ciento del tiempo que
intento acceder a ella, para recoger pasajeros
en cualquier momento del día.
• Como usuario que habla un idioma inglés,

quiero que la app permita en mi idioma
aprovechar las funcionalidades que ofrece
para usar el servicio cuando me encuentre de
paso por Perú.

3.3. BENEFICIOS
El objetivo principal de este artefacto es colocar a los

usuarios finales en el centro de la conversación y capturar
la funcionalidad del producto desde su perspectiva.
Por lo tanto, los desarrolladores obtienen una mejor

comprensión de qué, para quién y por qué están
construyendo.
A menudo los user stories se escriben en tarjetas o

post-its, utilizando la pared o tableros para facilitar la
planificación y discusión de forma práctica.
3.4. INVEST
Bil Wake inventó el acrónimo INVEST para describir las características de una buena historia.
Independiente: las historias pueden completarse en cualquier

I independt
orden.
Negociable: los detalles de la historia son cocreados por los

N negotiable
programadores y los clientes durante el desarrollo.
Valiosa: la funcionalidad es valiosa para los clientes o los

V valuable
usuarios del software.
Estimable: los developers deben poder realizar una estimación

E estimable
razonable para construir la historia.
Pequeña: las historias deberían construirse en poco tiempo,

S small generalmente alrededor de "días/persona". Se tienen que
poder construir varias historias en una iteración.
Comprobable: se debe poder escribir pruebas que verifiquen

T testable
que el software de la historia funcione adecuadamente.

3.5. WRITING A USER STORY
Pasos
1 4
Define Add
you end acceptance
user criteria
2 3
Specify Describe
what they the
want benefit
4. EPICS
Una epic (épica) es un user story grande que no se puede entregar como se define dentro
de una sola iteración, o es lo suficientemente grande como para que se pueda dividir en
casos de usuario más pequeños.
Building blocks
Main feature
User story
Theme Epic User story
User story
Major component
Story/Task 1 Subtask 1
Epic 1
Story/Task 2

Epic
Historia del usuario Historia del usuario
Tarea Tarea Tarea Tarea
No hay una forma estándar para representar epics. Algunos equipos usan los
formatos de historia de usuario familiares (As A, I want, So That o In Order To, As
A, I want), mientras que otros equipos representan las epics con una frase corta.
• Las epics nos proporcionan una visión de alto nivel de nuestros objetivos y cómo nos estamos
moviendo hacia ellos.
• Además, nos ayuda durante el proceso de priorización, ya que podemos verificar qué epics
requieren más atención y, por lo tanto, que user story deben implementarse primero.
Como usuario de la aplicación, quiero agregar fotos

User Story de perfil, para que más personas me escriban sobre
lo increíble que soy.
EPICS: Como administrador, quiero eliminar / bloquear fotos

GESTIÓN DE User Story de los perfiles de los usuarios para que no asusten a
PERFILES otras personas con sus fotos no adecuadas.
Como usuario de la aplicación, quiero tener un campo

User Story separado donde pueda contar más sobre mí, para que
las personas puedan seguir mi perfil.

5. THEMES
Un theme (tema) es un grupo de user stories que comparten un atributo común y se agrupan por
conveniencia.
Theme
“Build the promotion platform”
Epic Epic
‘’As a marketer, I want to create a promotion ‘’As a marketer, I want to create a segment so
so it can be used in a marketing campaign” it can be used to target specific audiences”
User Story User Story User Story User Story
As a marketer, I As a marketer, I As a marketer, I want As a marketer, I

want to enter a want to stablish a to view segment want to give my
discount amount so start and end date size relative to all segment a name so
it can be used when for my promotion consumers, so I I can easily access it
creating a discount so I can define can reach a critical within the platform.
promotion. validity. mass.
Theme
Increase Website Traffic
Epic Epic
Add new Video Section Improve Login Page Usability
User Story
User User As a user, I would like the validation on the
Story Story login page to be very clear so that I can easily
see when/if I make a mistake when I log in.
Task Task Task Task Task

Una aproximación para identificar themes es recurrir a los Business Goals.

Por ejemplo:
“Increase Website Traffic”.
Para el theme anterior, se puede identificar dos epics, “Add new Video Section” e “Improve
Login Page Usability”.
Wishlist Theme
As a customer, I want to be able to have wishlists so that I can

Epic
come back to buy products later.
As a customer, I want to be
As a customer, I want to be
able to save a product in my
able to view my wishlist so Stories
wishlist so that I can view it
that I can buy items from it.
again later.
Put ‘Add
Create new Create page to Add ‘View
to wishlist’ Tasks
db to store display user’s wishlist’ link to
button on each
wishlist items. wishlist. homepage.
product page.
En algunos casos, un término puede representar un theme, como por ejemplo “Wishlist”. A partir del
theme, se identifican los epics, user stories y tasks que permiten especificarlo.
6. BACKLOG
Product Backlog
Es una lista priorizada y ordenada de requisitos del Wish Lists

cliente (llamados Product Backlog items) de un proyecto, Product Backlog
expresados como User Stories.
Stakeholder 1
Es gestionado por el product owner, incluyendo su
contenido, disponibilidad y peticiones; además es él (el Product Owner
product owner) quien ordena el Product Backlog en base
al valor, riesgos, dependencias y necesidades de negocio. Stakeholder 2

¿Qué debería haber en el Product Backlog?
Requirement
• Todos los requisitos, funcionales y no
Requirement
funcionales, tareas, etc. deben ir en el Sprint 1
Product Backlog. Requirement
Requirement
Requirement
• Su contenido refleja todo el trabajo que Requirement
Sprint 2 + 3
el equipo de desarrollo tiene que hacer. Requirement
Requirement
Requirement
• En otras palabras, el equipo de
Sprint 4 Requirement
desarrollo no hace absolutamente nada
que no se encuentre en este listado. Requirement
Requirement
Caso: Taxi app
Código Descripción
Como conductor, quiero bloquear a los pasajeros que se portan

US01
mal para omitir su aparición en clientes vip.
Como pasajero, quiero vincular la tarjeta de crédito a mi perfil para pagar un

US02
viaje de forma rápida, fácil y sin efectivo.
Como conductor, quiero agregar fotos de mi automóvil en mi perfil para atraer

US03
a los usuarios.
Como pasajero, quiero varios drivers disponibles que se mostrarán de

US04
manera que pueda elegir la opción más adecuada para mí.
Como usuario, quiero ejecutar la app en el sistema operativo Android para

US05
acceder desde cualquier lugar a través de mi dispositivo móvil.
Como conductor, quiero que la app esté disponible el 99.999 por ciento
US06 del tiempo que intento acceder a ella, para recoger pasajeros en cualquier
momento del día.
Como usuario que habla un idioma inglés, quiero que la app permita en
US07 mi idioma aprovechar las funcionalidades que ofrece para usar el servicio
cuando me encuentre de paso por Perú.

7. AGILE PRODUCT ROADMAp

¿Qué es un Product Roadmap?
Es una fuente compartida que delinea la visión, dirección y progreso de un

producto en el tiempo.
Es un plan de acción que alinea la organización en torno a objetivos de corto

y largo plazo para el producto o proyecto, incluyendo cómo se van a alcanzar.
Proporciona un mejor entendimiento de la “foto completa”, que permite

a los miembros del equipo enfocarse en las tareas más importantes, evitar
confusiones en el alcance y tomar decisiones rápidas y autónomas.
Ejemplo
Product Plan Agile Roadmap
Sprint 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6

Jan 01 Jan 15 Jan 29 Feb 12 Feb 26 Mar 11 Mar 25
Release
Team 1 Jan 28 2020
Customer Interviews Demo v.1 Demo v.2

Shopping Cart Tech Support Portal Onboarding Flow Data Logging Module
Functionality Checkout Process Sensor Support DB Config
Import Functionality Demo Staging Back-End Upgrade Update Navigation Archiving
Team 2
Code Review Admin Console Automated Renewal System Integrations Update API
Ticketing System Additional Cloud Support Mobile Support Update Colos Mobile Web Perfomance
Team 3
Bootstrap Upgrade React Framework Design Iteration
Chrome Support IE Support Automated Tests Status Update Error Message Web App Overhaul
User Story 1 User Story 2 User Story 3 Undo Feature
• Un Agile Product Roadmap es lo mismo que un Product Roadmap, pero usualmente se

descompone en términos de Themes en vez de referencias basadas en el tiempo.
• Los Agile Roadmaps son más realistas y mantienen a todos alineados sobre qué va a suceder
en las próximas semanas y el resto se mantiene como una visión.

8. IMPACT MAP
Es una técnica de planeamiento estratégico que permite al equipo

establecer business goals y visualizar la manera y los medios para
alcanzar dichos goals.
Como su nombre lo indica, trata del impacto, buscando responder preguntas como:
¿Por qué queremos ¿Quién exactamente

¿Qué impacto? provocar ese impacto? será impactado?
WHY Se relaciona con el Goal
WHO Se relaciona con Actors o Personas
Se relaciona con el impacto. ¿Cómo exactamente desea que cambie

HOW el comportamiento?
Se refiere a los deliverables. ¿Qué puede hacer para que se produzcan

WHAT los impactos establecidos?
Los user stories traducen los deliverables en features específicos

USER STORIES que se van a implementar.
Aquí un ejemplo de Impact Map, donde se aprecia la relación entre los Business Goals, las Personas,
los Impacts, los Deliverables y los User Stories.
Business Goals + Personas + Impacts + Deliverables User Stories
As a paper clip
collector I want my
Buy more exclusive State clip’s paper clips to be
paper clips exclusiveness exclusive so other
collectors feel envy
Add facinating As a collector I want

Collector Buy more expensive stories about paper my paper clips to have
Increase the paper clips clips to emphasize history so they bring
weekly number of their uniquness more value to me
sales by 30%
As a student I want to
Buy more frequently have enough paper
Introduce discounts
and in bigger clips to hold all my
for student’s
ammounts papers and I want
them to be cheap
Student

9. CONCLUSIONES
• Un caso de uso es la descripción de una acción
o actividad. Un diagrama de caso de uso es
una descripción de las actividades que deberá
realizar alguien o algo para llevar a cabo algún
proceso.
• Las epics nos proporcionan una visión de alto

nivel de nuestros objetivos y cómo nos estamos
moviendo hacia ellos.
• Un user story describe la funcionalidad que

será valiosa para un usuario o comprador de
un sistema o software.
• Puedes planificar experimentos para validar

requisitos de software especificados, aplicando
métodos y frameworks de actualidad para
procesos de software.
Referencias
Para profundizar:
• https://online.visual-paradigm.com/diagrams/tutorials/use-case-diagram-tutorial/
• https://app.milanote.com/1IfiJ71adyLHew
• https://urtanta.com/historias-de-usuario/
• https://comunidad.iebschool.com/metodologiasparaelcambio/2014/03/27/escribiendo-
criterios-de-aceptacion-en-mis-historias-de-usuario/
• https://www.yodiz.com/blog/user-stories-acceptance-definition-and-criteria-in-agile-
methodologies/
• https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/product-backlog

< / >
< / >
< / >
< / >
< / >
USE CASE
< / >
< / >
< / >
< / >
< / >
< / >
< / >
©️ UPC. Todos los derechos reservados
Autor: Ángel Augusto Vasquez Nuñez

Si397 - S9 - Mad - Requirements Specification PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Si397 - S9 - Mad - Requirements Specification PDF

Cargado por

Copyright:

Formatos disponibles

< / >

Material producido por la Universidad Peruana de Ciencias Aplicadas

Agile producto roadmap 14

Material producido por la Universidad Peruana de Ciencias Aplicadas. UPC, 2021. 2

Al finalizar la unidad de aprendizaje, el estudiante planifica experimentos para validar

Un caso de uso describe la funcionalidad pero también debe

Los casos de uso proporcionan “valor para uno o más actores

Un modelo de CU está compuesto por dos partes:

Una parte textual llamada Use Case Specification

2.1. USE CASE SPECIFICATION

USE CASE SPECIFICATION - NOMBRE

Flow of Basic flow:

Material producido por la Universidad Peruana de Ciencias Aplicadas. UPC, 2021. 3

A good brief description Actor choices: one chosen for

Use – Case Specification – Register for Courses

1.2. CREATE SCHEDULE

1.3. SELECT COURSES

1.4. SUBMIT SCHEDULE

No references in the Steps have short

Material producido por la Universidad Peruana de Ciencias Aplicadas. UPC, 2021. 4

2.1. MODIFY A SCHEDULE

2.2 DELETE A SCHEDULE

2.3 DELETE A SUBMITTED SCHEDULE

2.4. UNIDENTIFIED STUDENT

2.6. QUIT AND SAVE

2.7. CANNOT ENROL

2.8. COURSE CATALOG UNAVAILABLE

2.9. REGISTRATION CLOSED

Flows have names

References use names,

Material producido por la Universidad Peruana de Ciencias Aplicadas. UPC, 2021. 5

Tests que evidencian y

El formato de la descripción de un user story es simple y breve:

Material producido por la Universidad Peruana de Ciencias Aplicadas. UPC, 2021. 6

• Como conductor, quiero bloquear a los pasajeros

• Como pasajero, quiero vincular la tarjeta de

• Como conductor, quiero agregar fotos de mi

• Como pasajero, quiero saber quiénes son los

• Como usuario, quiero ejecutar la app en el

• Como conductor, quiero que la app esté

• Como usuario que habla un idioma inglés,

Material producido por la Universidad Peruana de Ciencias Aplicadas. UPC, 2021. 7

El objetivo principal de este artefacto es colocar a los

Por lo tanto, los desarrolladores obtienen una mejor

A menudo los user stories se escriben en tarjetas o

Independiente: las historias pueden completarse en cualquier

Negociable: los detalles de la historia son cocreados por los

Valiosa: la funcionalidad es valiosa para los clientes o los

Estimable: los developers deben poder realizar una estimación

Pequeña: las historias deberían construirse en poco tiempo,

Comprobable: se debe poder escribir pruebas que verifiquen

Material producido por la Universidad Peruana de Ciencias Aplicadas. UPC, 2021. 8

3.5. WRITING A USER STORY

Theme Epic User story

Material producido por la Universidad Peruana de Ciencias Aplicadas. UPC, 2021. 9

Historia del usuario Historia del usuario

Tarea Tarea Tarea Tarea

Como usuario de la aplicación, quiero agregar fotos

EPICS: Como administrador, quiero eliminar / bloquear fotos

Como usuario de la aplicación, quiero tener un campo

Material producido por la Universidad Peruana de Ciencias Aplicadas. UPC, 2021. 10

User Story User Story User Story User Story

As a marketer, I As a marketer, I As a marketer, I want As a marketer, I