Home

pascar - Universidad Industrial de Santander

1. 91 MODELO DE DATOS E SS A E 95 Modelo de Datos Aplicaci n de Escritorio 95 Modelo de Datos Aplicaci n M vil 97 MANUALES DE USUARIO vaciando a as ey 98 Manual de Usuario Aplicaci n de 98 Manual de Usuario Aplicaci n 111 INTRODUCCI N Actualmente la industria del software muestra un crecimiento casi desmedido sin embargo no siempre satisface la demanda existente en el mercado y usualmente se encuentra una alta incidencia de fallos en los proyectos de software que son contratados para brindar soluciones La Ingenier a del Software se ha encargado del estudio y la difusi n de metodolog as y est ndares que optimicen el proceso del desarrollo de software y contribuyan a la elaboraci n de software de calidad Una de las reas de la Ingenier a de Software involucrada en el mejoramiento de los procesos del ciclo de vida del software es la Ingenier a de Requerimientos que interviene en la primera fase de desarrollo del software la fase de requerimientos que es considerada una de las m s importantes y de las cuales depende el xito o fracaso de un proyecto software En ste proyecto se describen algunos de los problemas que sufre la elaboraci n de proy
2. 12 2 3 T CNICAS USADAS EN LA INGENIER A DE REQUISITOS 12 2 4 EST NDAR IEEE 830 PR CTICA RECOMENDADA PARA LA ESPECIFIACCI N DE REQUERIMIENTOS DE 13 2 4 1 DEFINICIONES A 14 2 4 2 Consideraciones para producir una buena 5 5 14 2 4 2 1 La Naturaleza de la SRS 14 2 4 2 2 El Ambiente de la 5 5 15 2 4 2 3 Las Caracter sticas de una buena SRS 15 2 4 2 4 Preparaci n Conjunta de 5 5 17 2 4 2 5 La evoluci n de la SAS e 18 242 0 Prototipos irlanda 18 2 4 2 7 Generando el dise o en la 5 5 18 2 4 2 8 Generando los requisitos del proyecto en la 5 18 2 4 3 Las partes de una SRS fours ot hoses id send sweets 19 ZA Ts LIME OGWUCCION a A 19 y Es E EA 21 o e o A A 19 PA 1 2 19 2 4 3 1 3 Definiciones siglas 20 274 3514 Referencias cds 20 24 3 15 Apreciaci n Global 20 2 4 3 2 Descripci n d
3. 42 4 4 6 1 CASO DE USO Registrar 42 4 4 6 2 CASO DE USO Registrar tipos de 43 4 4 6 3 CASO DE USO Registrar 44 CONCEUSTONE S ios dives E O Sons eae rene nee 45 RECOMENDACIONES is a 46 REFERENCIAS BIBLIOGR FICAS occcoocccoocononononccnonccnnncnnoninonnanos 47 es 48 Tabla 1 Tabla 2 Tabla 3 Tabla 4 Tabla 5 Tabla 6 Tabla 7 Tabla 8 Tabla 9 Fases del Trabajo de la Ingenieria del Software Tabla Clientes Aplicaci n de escritorio Pascar Tabla Tipos de Atributos Aplicaci n de escritorio Pascar Tabla Atributos de Tipos de Atributos Aplicaci n de escritorio Pascar Tabla Proyectos Aplicaci n de escritorio Pascar Tabla Atributos de Proyectos Aplicaci n de escritorio Pascar Tabla Tipos de Requerimientos Aplicaci n de escritorio Pascar Tabla Atributos de Tipos de Requerimientos Aplicaci n de escritorio Pascar Tabla Requerimientos de Proyectos Aplicaci n de escritorio Pascar Tabla 10 Tabla 11 Tabla 12 Tabla 13 Tabla 14 Tabla 15 Tabla 16 Tabla 17 Tabla 18 Tabla 19 Tabla 20 Tabla 21 Tabla 22 Tabla 23 Tabla 24 Tabla 25 LISTA DE TABLAS Tabla Tipos de Usuarios Aplicaci n de escritorio Pascar Tabla Usuarios Aplicaci n de escritorio Pascar Tabla Dispositivos Aplicaci n de
4. VARCHAR 6 Nombre Id_Cliente Nombre_ Cli m_atributos VARCHAR 100 VARCHAR 10 VARCHAR 100 _tipos_de PK Cod_Atrib Nombre Cod_Tipo VARCHAR 10 VARCHAR 50 VARCHAR 10 m_tipos_descrip_proy PK Cod Tipo VARCHAR 10 8 4 MANUALES DE USUARIO 8 4 1 Manual de Usuario Aplicaci n de Escritorio 8 4 1 1 Inicio de la Aplicaci n Cuando se inicia la aplicaci n PASCAR aparece la ventana de autenticaci n de usuarios donde se deben ingresar el nombre de usuario Login y la contrase a password del usuario que va a ingresar a la aplicaci n eq PASCAR V1 0 Prototipo de Aplicaci n Software para la Captura y Administraci n de Requerimientos de Software Login Admin Password Prototipo Software presentado como proyecto de grado Adriana Rocio P rez Rojas Todos los derechos reservados 2006 Luego se selecciona la opci n Aceptar para validar si el usuario est no registrado en el sistema En el primer caso se dar acceso a la interfaz principal de la aplicaci n y en el segundo caso se emitir un mensaje de error y se restringe el acceso 8 4 1 2 Interfaz Principal La interfaz principal cuenta con 6 opciones de men Cada men cuenta con diferentes opciones que son habilitadas de acuerdo al perfil de usuario definido ya sea administrador con todas las opciones de la aplicaci n disponibles ingeniero de requerimientos con restricci n a las opciones a
5. la captura especificaci n documentaci n y administraci n de requerimientos de software desde un computador de escritorio que ser organizado en los siguientes m dulos principales e M dulo de Administraci n de Proyectos e M dulo de Especificaci n de Proyectos e M dulo de Especificaci n de Requerimientos e M dulo de Documentaci n e M dulo de Mantenimiento Dise ar e implementar un prototipo software para la captura y seguimiento de requerimientos de software desde un Asistente personal digital PDA Dise ar e implementar un software de sincronizaci n conduit entre la aplicaci n de escritorio y la aplicaci n m vil del PDA para la transferencia de datos entre los dos dispositivos Computador de escritorio y PDA 1 Es un proceso de comunicaci n entre la aplicaci n de escritorio y la aplicaci n m vil del PDA que implica una fase de sincronizaci n en la cual se intercambian y actualizan datos entre el dispositivo de escritorio y el dispositivo m vil PDA gt R ANALISTA DE CLIENTE ANALISTA DE SISTEMAS OFICINA DEL CLIENTE OFICINA DEL ANALISTA Figura 1 Representaci n del prototipo PASCAR 1 3 ALCANCES El proyecto PASCAR pretende ser un prototipo software que ayude a los ingenieros de sistemas u otros agentes involucrados en la administraci n de requerimientos de software no siendo as utilizado como herramienta nica e infalible pero s que pue
6. d Attributes What are the portability correctness maintainability security etc considerations e Design constraints imposed on an implementation Are there any required standards in effect imple mentation language policies for database integrity resource limits operating environment s etc The SRS writer s should avoid placing either design or project requirements in the SRS For recommended contents of an SRS see Clause 5 Copyright 1998 IEEE All rights reserved 3 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR 4 2 Environment of the SRS It is important to consider the part that the SRS plays in the total project plan which is defined in IEEE Std 610 12 1990 The software may contain essentially all the functionality of the project or it may be part of a larger system In the latter case typically there will be an SRS that will state the interfaces between the system and its software portion and will place external performance and functionality requirements upon the software portion Of course the SRS should then agree with and expand upon these system requirements IEEE Std 1074 1997 describes the steps in the software life cycle and the applicable inputs for each step Other standards such as those listed in Clause 2 relate to other parts of the software life cycle and so may complement software requirements Since the SRS has a specific role to play in the software development process the SRS writer s sho
7. v Tipos de Atributos En esta opci n se pueden crear modificar o eliminar tipos de atributos de un proyecto Estos atributos corresponden a tems descriptores donde se define el alcance del proyecto las definiciones acr nimos y abreviaturas utilizadas las referencias entre otros Si un tipo de atributo tiene registros relacionados en otras tablas no podr ser eliminado 101 Tipos de Atributos Crear Datos Generales C digo Nombre 1 Suposiciones y Dependencias Guardar Descripci n Lista cada uno de los factores que afectan los requisitos declarados en la SRS C digo Nombre Descripci n Cerrar Tipos Atributos Modificar Descripci n Eliminar Introducci n Alcance Definiciones Acronimos y Referencias Resumen Perspectivas del Producto Funciones del producto Caracter sticas de Usuario Aestrircinnes Generales DOO JM OMA AAA AAA Le Datos Generales C digo Nombre 1 Introducci n Modificar Descripci n pe 102 v Atributos Esta opci n permite crear modificar o eliminar atributos de los tipos de atributos de un proyecto Es decir estos atributos pertenecen a una Clasificaci n establecida anteriormente como tipo de atributo Por ejemplo si se cre un tipo de atributo llamado Alcance los atributos para ste tipo de atributo ser n Nombre del proyecto beneficios obtenidos objetivos metas entre otros Si un at
8. Prototype SRS outline 5 1 Introduction Section 1 of the SRS The introduction of the SRS should provide an overview of the entire SRS It should contain the following subsections a Purpose b Scope c Definitions acronyms and abbreviations d References e Overview 5 1 1 Purpose 1 1 of the SRS This subsection should a Delineate the purpose of the SRS b Specify the intended audience for the SRS 5 1 2 Scope 1 2 of the SRS This subsection should a Identify the software product s to be produced by name e g Host DBMS Report Generator etc b Explain what the software product s will and if necessary will not do c Describe the application of the software being specified including relevant benefits objectives and goals d Be consistent with similar statements in higher level specifications e g the system requirements specification if they exist Copyright 1998 IEEE All rights reserved 11 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR 5 1 3 Definitions acronyms and abbreviations 1 3 of the SRS This subsection should provide the definitions of all terms acronyms and abbreviations required to properly interpret the SRS This information may be provided by reference to one or more appendixes in the SRS or by reference to other documents 5 1 4 References 1 4 of the SRS This subsection should a Provide a complete list of all documents referenced elsewhere in the SRS
9. 30 4 1 METODOLOG A tati 30 4 2 FUNCIONALIDADES DE LA 31 4 ACTORES DE LA APLICACI N eeen 32 4 4 CASOS DE ASO id aio 32 4 4 1 Autenticaci n de USUAT OS ii ae ee eee 33 4 4 1 1 CASO DE USO Autenticaci n de Usuari0S 33 4 4 2 Gesti n de proyectos de 34 4 4 2 1 CASO DE USO Administraci n de 34 4 4 2 2 CASO DE USO Especificaci n de 35 4 4 3 Gesti n de Requerimientos de 37 4 4 3 1 CASO DE USO Registrar 37 4 4 3 2 CASO DE USO Actualizar 39 4 4 4 Generaci n de documentaci n de 39 4 4 4 1 CASO DE USO Generar Documento de SRS 40 4 4 5 Sincronizaci n de datos entre las dos 40 4 4 5 1 CASO DE USO Configurar 5 40 4 4 5 2 CASO DE USO Sincronizar DiSpOSitivOS 41 4 4 6 Mantenimiento del 5
10. 36 4 4 3 Gesti n de Requerimientos de Software Actualizar Requerimientos Ly Usuario crono Rea Funcionales de Escritorio Rea Dise o Registrar Rea Interfaces J Requerimientos Req Rendimiento Rea L gicos Usuario Aplicaci n M vil Rea Atributos Figura 6 Caso de Uso Gesti n de Requerimientos 4 4 3 1 CASO DE USO Registrar Requerimientos DESCRIPCI N Permite registrar los diferentes requerimientos que hacen parte de la SRS de un proyecto Estos requerimientos se clasifican de la siguiente manera e Requerimientos funcionales Hace referencia a los requisitos que describen la funcionalidad de una aplicaci n en funci n de sus entradas procesos y salidas e Requerimientos de rendimiento Describe el rendimiento que se espera del sistema en productivo como n mero de usuarios soportados simult neamente n mero de terminales n mero de transacciones por unidad de tiempo entre otros e Requerimientos de restricciones de dise o Hace referencia a las restricciones que se dan en la elaboraci n de un proyecto software debida a est ndares o pol ticas internas de las organizaciones proveedor y o cliente y a limitaciones en cuanto hardware y software e Requerimientos de interfaces externas Describe las interfaces de hardware software y usuario formatos de pantalla contenidos de reportes men s y la comunicaci n entre stas 37 e Requerimientos de atrib
11. 5 3 4 1 and 5 3 4 2 of IEEE EIA 12207 0 1996 28 Copyright 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 3 2 discusses compliance with the generic content guideline the kind of document noted in column 3 of Table B 1 as a description The generic content guidelines for a description appear in 5 1 of IEEE EIA 12207 1 1997 3 3 discusses compliance with the specific requirements for a Software Requirements Description noted in column 4 of Table B 1 as prescribed by 6 22 of IEEE EIA 12207 1 1997 3 4 discusses compliance with the life cycle data objectives of Annex of IEEE EIA 12207 0 1996 as described in 4 2 of IEEE EJA 12207 1 1997 B 3 1 Compliance with information requirements of IEEE EIA 12207 0 1996 The information requirements for an SRD are those prescribed by 5 1 1 4 5 3 4 1 and 5 3 4 2 of IEEE EIA 12207 0 1996 The requirements are substantively identical to those considered in B 3 3 of this recom mended practice B 3 2 Compliance with generic content guidelines of IEEE EIA 12207 1 1997 According to IEEE EIA 12207 1 1997 the generic content guideline for an SRD is generally a description as prescribed by 5 1 of IEER EIA 12207 1 1997 A complying description shall achieve the purpose stated in 5 1 1 and include the information listed in 5 1 2 of IEEE EIA 12207 1 1997 The purpose of a description is TEEE EIA 12207 1 1997 subclaus
12. c Optional Implies a class of functions that may or may not be worthwhile This gives the supplier the opportunity to propose something that exceeds the SRS 4 3 6 Verifiable An SRS is verifiable if and only if every requirement stated therein is verifiable A requirement is verifiable if and only if there exists some finite cost effective process with which a person or machine can check that the software product meets the requirement In general any ambiguous requirement is not verifiable Nonverifiable requirements include statements such as works well good human interface and shall usually happen These requirements cannot be verified because it is impossible to define the terms good well or usually The statement that the program shall never enter an infinite loop is nonverifiable because the testing of this quality is theoretically impossible An example of a verifiable statement is Output of the program shall be produced within 20 s of event x 60 of the time and shall be produced within 30 s of event x 100 of the time This statement can be verified because it uses concrete terms and measurable quantities If a method cannot be devised to determine whether the software meets a particular requirement then that requirement should be removed or revised Copyright 1998 IEEE All rights reserved 7 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR 4 3 7 Modifiable An SRS is modi
13. lo si cada requisito declarado es verificable Un requisito es verificable si y s lo si all existe alg n proceso por el cual una persona o m quina puede comprobar que el producto software tiene el requisito En general cualquier requisito ambiguo no es verificable Los requisitos que incluyen frases como trabaja bien interface humana buena y normalmente pasar no pueden verificarse porque es imposible definir las condiciones bueno bien o normalmente Un ejemplo de una declaraci n verificable es La salida del programa se producir dentro de 20 segundos del evento el 60 del tiempo y se producir dentro de 30 segundos del evento el 100 del tiempo Esta declaraci n puede verificarse porque usa condiciones concretas y cantidades mensurables Y Modificable Una SRS es modificable si y s lo si su estructura y estilo son tales que puede hacerse cualquier cambio a los requisitos de forma f cil completa y consistentemente mientras conserva la estructura y estilo La redundancia no es un error pero puede llevar f cilmente a los errores La redundancia puede ayudar a hacer una SRS m s legible de vez en cuando pero un problema puede generarse cuando el documento redundante se actualiza Por ejemplo un requisito puede alterarse en un solo lugar d nde aparece Entonces la SRS se pone incoherente Siempre que la redundancia sea necesaria la SRS debe incluir referencias cruzadas hacerlo modificable Y Tra
14. 2 Functional requirements 3 2 1 Stimulus 1 3 2 1 1 Functional requirement 1 1 3 2 1 n Functional requirement 1 n 3 2 2 Stimulus 2 3 2 m Stimulus m 3 2 m 1 Functional requirement m 1 3 2 m n Functional requirement m n 3 3 Performance requirements 3 4 Design constraints 3 5 Software system attributes 3 6 Other requirements A 7 Template of SRS Section 3 organized by functional hierarchy 3 Specific requirements 3 1 External interface requirements 3 1 1 User interfaces 3 1 2 Hardware interfaces 3 1 3 Software interfaces 3 14 Communications interfaces 3 2 Functional requirements 3 2 1 Information flows 3 2 1 1 Data flow diagram 1 3 2 1 1 1 Data entities 3 2 1 1 2 Pertinent processes 3 2 1 1 3 Topology 3 2 1 2 Data flow diagram 2 3 2 1 2 1 Data entities 3 2 1 2 2 Pertinent processes 3 2 1 2 3 Topology 3 2 1 n Data flow diagram n 24 Copyright 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 3 2 1 n 1 Data entities 3 2 1 n 2 Pertinent processes 3 2 1 n 3 Topology 3 2 2 Process descriptions 3 2 2 1 Process 1 3 2 2 1 1 Input data entities 3 2 2 1 2 Algorithm or formula of process 3 2 2 1 3 Affected data entities 3 2 2 2 Process 2 3 2 2 2 1 Input data entities 3 2 2 2 2 Algorithm or formula of process 3 2 2 2 3 Affected data entities 3 2 2 m Process m 3 2 2 m 1 Input data entities 3 2 2 m 2 Algorithm or formula of process 3 2 2 m 3 Affected data entities 3 2 3 Data constru
15. 3 4 1 Tabla de contenidos e ndice La tabla de contenidos e ndice es bastante importante y debe seguir las pr cticas de composiciones generales 2 4 3 4 2 Ap ndices Los ap ndices no siempre son considerados parte de la SRS real y no siempre son necesarios Ellos pueden incluir 26 a Ejemplos de formatos de las entradas salidas descripciones del an lisis del costo o resultados de estudios del usuario b Informaci n a fondo que puede ayudar a los lectores del SRS c Una descripci n de los problemas a ser resueltos por el software Cuando los ap ndices son incluidos la SRS debe declarar expl citamente si los ap ndices ser n considerados parte de los requisitos o no Para este proyecto se decidi hacer una agrupaci n del est ndar para obtener una estructura de la siguiente manera Primero se clasificaron como atributos descriptores del proyecto la Introducci n y Descripci n Global con sus items a atributos correspondientes y se dej como pieza principal la parte de Requisitos Espec ficos con sus atributos respectivos es decir la estructura tom la siguiente forma ATRIBUTOS DEL PROYECTO 1 Introducci n 1 1 Prop sito 1 2 Alcance 1 3 Definiciones siglas y abreviaciones 1 4 Referencias 1 5 Apreciaci n global 2 Descripci n global 2 1 Perspectiva del producto 2 2 Funciones del producto 2 3 Caracter sticas del usuario 2 4 Restricciones 2 5 Suposiciones y dependencias
16. 4 3 2 1 Perspectiva del producto Esta subdivisi n de la SRS debe poner el producto en perspectiva con otros productos relacionados Si el producto es independiente y totalmente aut nomo debe declararse que as es Si la SRS define un producto que es un componente de un sistema m s grande como frecuentemente ocurre entonces esta subdivisi n debe relacionar los requisitos de ese sistema m s grande a la funcionalidad del software y debe identificar las interfaces entre ese sistema y el software Un diagrama del bloque que muestra los 20 componentes mayores del sistema mas grande las interconexiones las interfaces externas pueden ser utiles Esta subdivisi n tambi n debe describir c mo el software opera dentro de varias restricciones Por ejemplo estas restricciones podr an incluir a Interfaces del sistema Esto debe listar cada interfaz del sistema y debe identificar la funcionalidad del software para satisfacer el requisito del sistema y la descripci n de la interfaz para empatar el sistema b Interfaces con el usuario Esto debe especificar a lo siguiente a Las caracter sticas l gicas de cada interfaz entre el producto software y sus usuarios Esto incluye las caracter sticas de la configuraci n por ejemplo formatos de la pantalla requeridos p gina o esquemas de la ventana los reportes o men s entre otros necesaria para satisfacer los requisitos del software b Todos los aspectos para optimizar la inter
17. 4 Maintainability This should specify attributes of software that relate to the ease of maintenance of the software itself There may be some requirement for certain modularity interfaces complexity etc Requirements should not be placed here just because they are thought to be good design practices 5 3 6 5 Portability This should specify attributes of software that relate to the ease of porting the software to other host machines and or operating systems This may include the following a Percentage of components with host dependent code b Percentage of code that is host dependent c Use of a proven portable language d Use of a particular compiler or language subset e Use of a particular operating system 5 3 7 Organizing the specific requirements For anything but trivial systems the detailed requirements tend to be extensive For this reason it is recom mended that careful consideration be given to organizing these in a manner optimal for understanding There is no one optimal organization for all systems Different classes of systems lend themselves to different orga nizations of requirements in Section 3 of the SRS Some of these organizations are described in 5 3 7 1 through 5 3 7 7 5 3 7 1 System mode Some systems behave quite differently depending on the mode of operation For example a control system may have different sets of functions depending on its mode training normal or emergency When organiz ing th
18. Escritorio 4 4 5 1 CASO DE USO Configurar Sincronizaci n DESCRIPCI N En este caso de uso se permite configurar e instalar la aplicaci n m vil y las tablas de datos de la aplicaci n 40 RESTRICCIONES Debe existir los archivos correspondientes para el proceso de instalaci n y sincronizaci n Adem s la aplicaci n que administra la sincronizaci n del dispositivo debe estar instalada en el computador de escritorio y en ejecuci n con el registro del dispositivo que se va a sincronizar PROCESO e El usuario selecciona la opci n para instalar la aplicaci n m vil desde la aplicaci n de escritorio e Luego selecciona el dispositivo correspondiente al que se le va a instalar la aplicaci n El usuario selecciona la opci n Aceptar e El sistema transfiere al PDA lo que el usuario le ha ordenado instalar ENTRADAS DEL PROCESO El usuario selecciona el dispositivo para realizar la instalaci n SALIDAS DEL PROCESO El dispositivo m vil se encuentra actualizado con la nueva instalaci n 4 4 5 2 CASO DE USO Sincronizar Dispositivos DESCRIPCI N Permite realizar la sincronizaci n para la actualizaci n de datos entre la aplicaci n m vil y la de escritorio RESTRICCIONES Debe existir los archivos correspondientes para el proceso de sincronizaci n Adem s la aplicaci n Hotsync Manager debe estar instalada en el computador de escritorio y en ejecuci n con el registro del dispositivo que se va a sincronizar
19. INGENIER A DE REQUISITOS Dependiendo del proyecto software a desarrollar pueden utilizarse t cnicas de la IR como herramienta para el desarrollo de las actividades descritas anteriormente Algunas de stas t cnicas de describen a continuaci n e Entrevistas Generalmente van acompa adas de cuestionarios donde el analista de sistemas interroga al cliente de manera abierta y sin presi n Es ideal al comienzo del proyecto ya que ayuda a dar una idea global del 12 problema teniendo en cuenta el punto de vista de los usuarios involucrados quienes pueden ser los gerentes usuarios de sistemas antiguos y usuarios potenciales de la aplicaci n a desarrollar e Lluvia de ideas Pretende que los involucrados en un proyecto desarrollen su creatividad y propongan la mayor cantidad de ideas posibles de modo que se puedan analizar y llegar a elegir la ptima e Prototipos Luego de la definici n de los requerimientos el equipo de desarrollo puede realizar modelos preliminares del producto software llamados prototipos que a trav s de un dise o r pido y teniendo en cuenta los aspectos m s globales de la definici n de requisitos realizada proveen alguna funcionalidad al cliente el cual debe realizar un refinamiento de los requerimientos y realimentar el modelo propuesto por el prototipo ste es un proceso iterativo que puede darse hasta la entrega del proyecto donde los requerimientos son satisfechos a cabalidad e Casos de uso Propon
20. In such cases organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification For example see A 8 for an organization combining user class and feature Any additional requirements may be put in a separate section at the end of the SRS There are many notations methods and automated support tools available to aid in the documentation of requirements For the most part their usefulness is a function of organization For example when organizing by mode finite state machines or state charts may prove helpful when organizing by object object oriented Copyright 1998 IEEE All rights reserved 19 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR analysis may prove helpful when organizing by feature stimulus response sequences may prove helpful and when organizing by functional hierarchy data flow diagrams and data dictionaries may prove helpful In any of the outlines given in A 1 through A 8 those sections called Functional Requirement 7 may be described in native language e g English in pseudocode in a system definition language or in four sub sections titled Introduction Inputs Processing and Outputs 5 4 Supporting information The supporting information makes the SRS easier to use It includes the following a Table of contents b Index c Appendixes 5 4 1 Table of contents and index The table of contents and index are quite important and should
21. Information Technology Software life cycle pro cesses Life cycle data IEEE EIA 12207 2 1997 IEEE EIA Guide for Information Technology Software life cycle pro cesses Implementation considerations and Additions to 11 SESC standards i e IEEE Stds 730 828 829 830 1012 1016 1058 1062 1219 1233 1362 to define the correlation between the data produced by existing SESC standards and the data produced by the application of IEEE EIA 12207 1 1997 NOTE Although IEEE EIA 12207 1 1997 is a guide it also contains provisions for application as a standard with spe cific compliance requirements This annex treats 12207 1 1997 as a standard B 1 1 Scope and purpose Both IEEE Std 830 1998 and 12207 1 1997 place requirements on a Software Requirements Description Document The purpose of this annex is to explain the relationship between the two sets of requirements so that users producing documents intended to comply with both standards may do so B 2 Correlation This clause explains the relationship between IEEE Std 830 1998 and IEER EIA 12207 0 1996 IEEE EIA 12207 1 1997 in the following areas terminology process and life cycle data B 2 1 Terminology correlation Both this recommended practice and IEEE EIA 12207 0 1996 have similar semantics for the key terms of software requirements specification supplier developer and maintainer This recommended practice uses Copyright O 1
22. PROCESO e El usuario selecciona la opci n para sincronizar la aplicaci n desde la aplicaci n de escritorio e El sistema ejecuta la sincronizaci n a trav s del conduit e El sistema realiza el intercambio actualizaci n de datos correspondiente ENTRADAS DEL PROCESO El usuario selecciona la opci n para realizar la sincronizaci n 41 e SALIDAS DEL PROCESO La salida que se produce est directamente ligada con la actualizaci n de los datos en la tabla correspondiente en la base de datos 4 4 6 Mantenimiento del Sistema Actualizar Usuarios Registrar Usuarios Registrar Tipos de Requerimientos Actualizar Tipos Requerimientos Registrar Dispositivos Actualizar Dispositivos Usuario Aplicaci n de Escritorio Actualizar Clientes Registrar Clientes Figura 9 Caso de Uso Mantenimiento del Sistema 4 4 6 1 CASO DE USO Registrar Usuarios e DESCRIPCI N En este caso de uso se permite registrar modificar o eliminar los usuarios que intervienen en la SRS e RESTRICCIONES El nico usuario autorizado para realizar las tareas de registro y actualizaci n mencionadas es el administrador del sistema No se podr eliminar un usuario que tenga registros relacionados e PROCESO e El usuario selecciona la opci n Usuarios e El usuario ingresa los datos correspondientes para registrar un nuevo usuario o para actualizar e Luego de validados los da
23. Practice for Software Requirements Specifications se presenta a continuaci n en las siguientes p ginas 48 IEEE Std 830 1998 Revision of IEEE Std 830 1993 IEEE Recommended Practice for Software Requirements Specifications Sponsor Software Engineering Standards Committee of the IEEE Computer Society Approved 25 June 1998 IEEE SA Standards Board Abstract The content and qualities of a good software requirements specification SRS are de scribed and several sample SRS outlines are presented This recommended practice is aimed at specifying requirements of software to be developed but also can be applied to assist in the selec tion of in house and commercial software products Guidelines for compliance with IEEE EIA 12207 1 1997 are also provided Keywords contract customer prototyping software requirements specification supplier system requirements specifications The Institute of Electrical and Electronics Engineers Inc 345 East 47th Street New York NY 10017 2394 USA Copyright 1998 by the Institute of Electrical and Electronics Engineers Inc All rights reserved Published 1998 Printed in the United States of America ISBN 0 7381 0332 2 No part of this publication may be reproduced in any form in an electronic retrieval system or otherwise without the prior written permission of the publisher IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinat ing Co
24. VARCHAR 10 Hora de modificaci n del atributo del proyecto Usuario_Modif VARCHAR 10 Usuario que modific el atributo del proyecto Tabla 6 Tabla Atributos de Proyectos Aplicaci n de escritorio Pascar 87 Tbl_TIPOS_REQ Descripci n Almacena los tipos de requerimientos que se utilizan para detallar un proyecto Tbl_TIPOS_REQ CAMPO TIPO LONG DESCRIPCI N Codigo_Tipo VARCHAR 10 Identifica un tipo de requerimiento Nombre VARCHAR 50 Nombre del tipo de requerimiento Descripcion VARCHAR 100 Descripci n del tipo de requerimiento Tabla 7 Tabla Tipos de Requerimientos Aplicaci n de escritorio Pascar Nombre Tabla Tbl_ATRIBUTOS_TIPOS_REQ Descripci n Almacena los atributos correspondientes a un tipo de requerimientos Tbl_ ATRIBUTOS_TIPOS_REQ CAMPO TIPO LONG DESCRIPCI N Codigo_Atributo VARCHAR 10 Identifica el atributo de un tipo de requerimiento determinado Nombre del atributo de un tipo de Nombre VARCHAR 50 Posh requerimiento Descripcion VARCHAR 100 Describe el atributo de un tipo de requerimiento Codigo_Tipo VARCHAR 10 Identifica el tipo de requerimiento al que pertenece el atributo Tabla 8 Tabla Atributos de Tipos de Requerimientos Aplicaci n de escritorio Pascar Nombre Tabla REQUERIMIENTOS Descripci n Almacena los requerimientos de cada proyecto _ REQUERI MIENTOS CA
25. a las necesidades de una organizaci n El producto obtenido permite entonces administrar los requerimientos de un proyecto software de manera flexible y ser administrado para hacerlo m s adaptable a los procesos que maneje la organizaci n que lo utilice Este proyecto no estuvo enfocado a una entidad espec fica pero quiso fomentar el inter s por el trabajo en la l nea de investigaci n de Ingenier a del Software en la Escuela de Ingenier a de Sistemas e Inform tica Es por esto que ste trabajo de grado va dirigido a cualquier organizaci n cuyo objeto sea la elaboraci n y el desarrollo de soluciones software que pretendan aplicar metodolog as para el mejoramiento de las fases tempranas del desarrollo del software en especial que se inclinen por una mejor administraci n de los requerimientos de sus proyectos software En nuestro medio se hace necesario tomar conciencia que la elaboraci n de proyectos software no puede seguirse haciendo de manera artesanal Se necesita personal capacitado para dirigir proyectos inform ticos y que est n preparados entre otras cosas en las reas de ingenier a del software y afines de modo que puedan dar un mejor cauce a los proyectos La ingenier a de requerimientos no es un proceso aislado requiere del trabajo conjunto de ingenieros clientes usuarios administradores equipo de desarrollo que debe tener un nivel de experiencia m nimo y el dominio del rea del problema para conseguir los resu
26. attention Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of Electrical and Electronics Engineers Inc provided that the appropriate fee is paid to Copyright Clearance Center To arrange for payment of licensing fee please contact Copyright Clearance Center Customer Service 222 Rosewood Drive Danvers MA 01923 USA 978 750 8400 Permission to photocopy portions of any individual standard for educational class room use can also be obtained through the Copyright Clearance Center Introduction This introduction is not a part of IEEE Std 830 1998 IEEE Recommended Practice for Software Requirements Specifi cations This recommended practice describes recommended approaches for the specification of software require ments It is based on a model in which the result of the software requirements specification process is an unambiguous and complete specification document It should help a Software customers to accurately describe what they wish to obtain b Software suppliers to understand exactly what the customer wants c Individuals to accomplish the following goals 1 Develop a standard software requirements specification SRS outline for their own organiza tions 2 Define the format and content of their specific software requirements specifications 3 Develop additional local supporting items such as an SRS quality checklist or an SRS writer s han
27. b Identify each document by title report number if applicable date and publishing organization c Specify the sources from which the references can be obtained This information may be provided by reference to an appendix or to another document 5 1 5 Overview 1 5 of the SRS This subsection should a Describe what the rest of the SRS contains b Explain how the SRS is organized 5 2 Overall description Section 2 of the SRS This section of the SRS should describe the general factors that affect the product and its requirements This section does not state specific requirements Instead it provides a background for those requirements which are defined in detail in Section 3 of the SRS and makes them easier to understand This section usually consists of six subsections as follows a Product perspective b Product functions c User characteristics d Constraints e Assumptions and dependencies f Apportioning of requirements 5 2 1 Product perspective 2 1 of the SRS This subsection of the SRS should put the product into perspective with other related products If the product is independent and totally self contained it should be so stated here If the SRS defines a product that is a component of a larger system as frequently occurs then this subsection should relate the requirements of that larger system to functionality of the software and should identify interfaces between that system and the software A
28. block diagram showing the major components of the larger system interconnections and external inter faces can be helpful 12 Copyright 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 This subsection should also describe how the software operates inside various constraints For example these constraints could include a System interfaces b User interfaces c Hardware interfaces d Software interfaces e Communications interfaces f Memory g Operations h Site adaptation requirements 5 2 1 1 System interfaces This should list each system interface and identify the functionality of the software to accomplish the system requirement and the interface description to match the system 5 2 1 2 User interfaces This should specify the following a The logical characteristics of each interface between the software product and its users This includes those configuration characteristics e g required screen formats page or window layouts content of any reports or menus or availability of programmable function keys necessary to accom plish the software requirements b All the aspects of optimizing the interface with the person who must use the system This may simply comprise a list of do s and don ts on how the system will appear to the user One example may be a requirement for the option of long or short error messages Like all others these requirements should be v
29. follow general compositional practices 5 4 2 Appendixes The appendixes are not always considered part of the actual SRS and are not always necessary They may include a Sample input output formats descriptions of cost analysis studies or results of user surveys b Supporting or background information that can help the readers of the SRS A description of the problems to be solved by the software d Special packaging instructions for the code and the media to meet security export initial loading or other requirements When appendixes are included the SRS should explicitly state whether or not the appendixes are to be considered part of the requirements 20 Copyright O 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 Annex A informative SRS templates A 1 Template of SRS Section 3 organized by mode Version 1 3 Specific requirements 3 1 3 2 3 3 3 4 3 5 3 6 External interface requirements 3 1 1 User interfaces 3 1 2 Hardware interfaces 3 1 3 Software interfaces 3 1 4 Communications interfaces Functional requirements 3 2 1 Model 3 2 1 1 Functional requirement 1 1 3 2 1 n Functional requirement 1 n 3 22 Mode 2 3 2 m Modem 3 2 m 1 Functional requirement m 1 3 2 m n Functional requirement m n Performance requirements Design constraints Software system attributes Other requirements A 2 Template of SRS Section 3 organized by mode Version 2 3
30. invoice preparation without mentioning the vast amount of detail that each of those functions requires Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher level specification if one exists that allocates particular functions to the software product Note that for the sake of clarity a The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time b Textual or graphical methods can be used to show the different functions and their relationships Such a diagram is not intended to show a design of a product but simply shows the logical relation ships among variables 14 Copyright O 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 5 2 3 User characteristics 2 3 of the SRS This subsection of the SRS should describe those general characteristics of the intended users of the product including educational level experience and technical expertise It should not be used to state specific requirements but rather should provide the reasons why certain specific requirements are later specified in Section 3 of the SRS 5 2 4 Constraints 2 4 of the SRS This subsection of the SRS should provide a general description of any other items that will limit the devel oper s options These include a Regulatory policies b Hardware limit
31. los diferentes niveles de descripci n de los requerimientos como requerimientos de dise o de interfaces de seguridad restricciones entre otros y se termina por agrupar diferentes requerimientos en uno solo u omiti ndose requerimientos que pueden ser importantes eLa especificaci n de requerimientos se hace de forma incompleta imprecisa desordenada e inconsistente entre otras cosas por falta de preparaci n del personal que esta encargado de esta tarea porque no se conocen ni utilizan est ndares o formatos para la captura especificaci n organizaci n y documentaci n de requerimientos que facilite la administraci n de los mismos en especial cuando se generan cambios en las especificaciones a lo largo del proyecto Esto puede hacer que el proyecto software sufra retrasos en el cronograma e incremente los costos pues no hay una apropiada documentaci n de los requerimientos que facilite su gesti n eLas pruebas del software fallan La falta de documentaci n de requisitos puede ocasionar que no se planeen buenas pruebas para el software antes que el producto sea entregado comprometiendo su calidad eCuando no se provee la documentaci n detallada de requerimientos de un producto software se dificulta su mantenimiento y la obtenci n de nuevas versiones y actualizaciones del mismo Estos son los principales s ntomas y efectos que ocasionan una deficiencia notable en la especificaci n y administraci n organizada de r
32. los requerimientos de un proyecto algunos de los cuales ser n seleccionados por el usuario corresponden a datos tomados de la base de datos para definir el tipo de requerimiento y sus atributos y otros ingresados manualmente SALIDAS DEL PROCESO La salida que se produce est directamente ligada con la inserci n de los datos en la tabla correspondiente en la base de datos En caso que los datos no sean ingresados correctamente se emitir n los respectivos mensajes de error 38 4 4 3 2 CASO DE USO Actualizar Requerimientos e DESCRIPCI N Se podran actualizar los diferentes requerimientos que hagan parte de la SRS de un proyecto software e RESTRICCIONES Solo se podr modificar la descripci n de un atributo que haga parte de la definici n de un requerimiento creado previamente El ld de un requerimiento no podr ser cambiado e PROCESO e El usuario selecciona la opci n Modificar Requerimientos e El sistema presenta la informaci n de los requerimientos de un proyecto para que puedan ser seleccionados y modificados e El sistema debe validar que no se encuentren vac os los campos que se consideren obligatorios para la definici n de un requerimiento e Luego de ingresar la informaci n el usuario hace clic en la opci n Guardar e Si la informaci n ha sido ingresada correctamente se actualiza la informaci n en la base de datos e ENTRADAS DEL PROCESO Todas las entradas del proceso est n dadas por las solicit
33. n pero no se considera apropiado para quienes utilizan como metodolog a el desarrollo r pido de aplicaciones DRA 13 De acuerdo al est ndar una buena SRS deber a proveer entre otros los siguientes beneficios e Establecer las bases de acuerdo de lo que tiene que hacer el software entre el cliente y el proveedor que desarrolla el software e Reducir el esfuerzo de desarrollo de modo que se haga una especificaci n rigurosa antes de empezar la fase de dise o del software e Proveer una base de estimaci n de costos y cronograma del proyecto e Proveer una base para la validaci n y verificaci n de requerimientos En adelante se expondr n algunos aspectos que est n contemplados en el est ndar para poder obtener una visi n general de su contenido y de su uso en la SRS 2 4 1 Definiciones En general las definiciones de los t rminos usados en estas especificaciones est n conforme a las definiciones proporcionadas en IEEE Std 610 12 1990 e Contrato Es un documento legal y en el estar n de acuerdo las partes del cliente y proveedor Esto incluye los requisitos t cnicos y requerimientos de la organizaci n costo y tiempo para un producto Un contrato tambi n puede contener la informaci n informal pero til como los compromisos o expectativas de las partes involucradas e Cliente Es la persona que pagan por el producto y normalmente pero no necesariamente definen los requisitos En la pr ctica el cliente y el prov
34. pol ticas para la integridad del banco de datos l mites de los recursos ambiente de operaci n etc 2 4 2 2 El Ambiente de la SRS Es importante considerar el papel que juega la SRS en el dise o del proyecto total el cual se define en IEEE Std 610 12 1990 El software puede contener toda la funcionalidad del proyecto esencialmente o puede ser parte de un sistema m s grande En el ltimo caso habr una SRS que declarar las interfaces entre el sistema y su software modular y la funcionalidad entre las dos Desde que la SRS tiene un papel espec fico en el proceso de desarrollo de software el que define la SRS debe tener el cuidado para no ir m s all de los l mites de ese papel Esto significa que a Debe definir todos los requisitos del software correctamente b No debe describir ni el dise o ni los detalles de la implementaci n stos deben describirse en la fase de dise o del proyecto No debe imponer restricciones adicionales al software stas se especifican propiamente en otros documentos 2 4 2 3 Las Caracter sticas de una buena SRS Y Correcta Una SRS es correcta si y s lo si cada requisito declarado se encuentra en el software No hay ninguna herramienta o procedimiento que aseguren la exactitud Alternativamente el cliente o el usuario pueden determinar si la SRS refleja las necesidades reales correctamente Identificando los requerimientos hace este procedimiento m s f cil y hay menos prob
35. que modific el cliente Tabla 2 Tabla Clientes Aplicaci n de escritorio Pascar e Nombre Tabla Tbl_TIPOS_DESCRIP_PROY e Descripci n Almacena los tipos de descripci n que se utilizan para detallar un proyecto _DESCRIP_PROY TIPO LONG DESCRIPCI N Codigo Tipo VARCHAR 10 Identifica un tipo de descripci n de un proyecto Nombre VARCHAR 50 Nombre del tipo de descripci n Descripcion VARCHAR 100 Descripci n del tipo de descripci n de un proyecto Tabla 3 Tabla Tipos de Atributos Aplicaci n de escritorio Pascar e Nombre Tabla Tbl_ATRIBUTOS_TIPOS_DESCRIP_PROY e Descripci n Almacena los atributos correspondientes a un tipo de descripci n de proyectos Tbl_ATRIBUTOS_TIPOS_DESCRIP_PROY CAMPO TIPO LONG DESCRIPCI N Identifica el atributo que pertenece a un tipo de Codigo_Atributo VARCHAR 10 descripci n de un proyecto Nombre VARCHAR 50 Nombre del atributo 86 Descripcion VARCHAR 100 Descripci n del atributo Codigo_ Tipo VARCHAR 10 ae a que tipo de descripci n pertenece el Tabla 4 Tabla Atributos de Tipos de Atributos Aplicaci n de escritorio Pascar e Nombre Tabla Tbl_PROYECTOS e Descripci n Almacena los datos identificadores de cada proyecto Tbl_ PROYECTOS CAMPO TIPO LONG DESCRIPCI N C digo Unico alfa num rico que representa Codigo Proye
36. software item 5 3 2 Functions Physical characteristics and environ including 5 3 3 Performance requirements mental conditions should be Performance requirements provided Physical characteristics Environmental conditions d Requirements for interfaces 5 3 1 External interfaces external to software item e Qualification requirements The requirements to be used for qualification testing should be provided or referenced f Safety specifications 5 2 4 Constraints g Security and privacy 5 3 6 3 Security specifications h Human factors engineering 5 2 3 User characteristics requirements 5 2 1 2 User interfaces i Data definition and database 5 3 4 Logical data base requirements requirements j Installation and acceptance 5 2 1 8 Site adaptation requirements Installation and acceptance require requirements at operation site ments at operation site k Installation and acceptance Installation and acceptance require requirements at maintenance site ments at maintenance site 1 User documentation requirements User documentation requirements m User operation and execution 5 2 1 7 Operations User execution requirements requirements 30 Copyright 1998 IEEE All rights reserved SOFTWARE REQUIREMENTS SPECIFICATIONS IEEE Std 830 1998 Table B 3 Coverage of specific SRD requirements by IEEE Std 830 1998 continued TEEE EIA 12207 1 1997 specific cont
37. systems These requirements should include at a minimum a description of every input stimulus into the system every output response from the system and all functions performed by the system in response to an input or in support of an output As this is often the largest and most impor tant part of the SRS the following principles apply a Specific requirements should be stated in conformance with all the characteristics described in 4 3 b Specific requirements should be cross referenced to earlier documents that relate c requirements should be uniquely identifiable d Careful attention should be given to organizing the requirements to maximize readability Copyright 1998 IEEE All rights reserved 15 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR Before examining specific ways of organizing the requirements it is helpful to understand the various items that comprise requirements as described in 5 3 1 through 5 3 7 5 3 1 External interfaces This should be a detailed description of all inputs into and outputs from the software system It should complement the interface descriptions in 5 2 and should not repeat information there It should include both content and format as follows a Name of item b Description of purpose c Source of input or destination of output d Valid range accuracy and or tolerance e Units of measure f Timing g Relationships to other inputs outputs h Screen formats organ
38. usuarios Tbl_USUARIOS CAMPO TIPO LON G DESCRIPCI N Codigo_Usuario VARCHAR 10 Identifica a un usuario determinado Puede ser su NIT o c dula de identificaci n Nombres VARCHAR 50 Nombre s del usuario Apellidos VARCHAR 50 Apellido s del usuario Login VARCHAR 10 Login de autenticaci n del usuario Password VARCHAR 10 Contrase a de autenticaci n del usuario Codigo Tipo VARCHAR 10 Identifica el tipo de usuario Tabla 11 Tabla Usuarios Aplicaci n de escritorio Pascar Tbl_DISPOSITIVOS Descripci n Almacena la identificaci n de los dispositivos disponibles Tbl_ DISPOSITIVOS CAMPO TIPO LONG DESCRIPCI N Nombre VARCHAR 50 Nombre del dispositivo Nota LONGCHAR Anotaci n Descripci n del dispositivo Codigo_Usuario VARCHAR 10 pr del usuario responsable del ispositivo Tabla 12 Tabla Dispositivos Aplicaci n de escritorio Pascar Nombre Tabla Tbl_ RECOMENDACIONES Descripci n Almacena las recomendaciones realizadas dentro de un proyecto por los usuarios Tbl_ RECOMENDACIONES CAMPO TIPO LONG DESCRIPCI N Coaige_Recomend vARCHAR 10 sue Mente a recomendaci n Nombre_Recomend LONGCHAR Nombre descriptivo de la recomendaci n realizada 89 Descripcion LONGCHAR Descripcion detallada de la recomendaci n realizada al proyecto Fecha_Crea VARCHAR 10 Fecha en la que
39. 992 IEEE Standard Taxonomy for Software Engineering Standards IEEE Std 1012 1998 IEEE Standard for Software Verification and Validation TEEE Std 1012a 1998 IEEE Standard for Software Verification and Validation Content Map to IEEE EIA 12207 1 1997 4 TEEE Std 1016 1998 IEEE Recommended Practice for Software Design Descriptions IEEE Std 1028 1997 IEEE Standard for Software Reviews TEEE Std 1042 1987 Reaff 1993 IEEE Guide to Software Configuration Management IEEE P1058 D2 1 Draft Standard for Software Project Management Plans dated 5 August 1998 6 TEEE Std 1058a 1998 IEEE Standard for Software Project Management Plans Content to 12207 1 1997 7 TEEE Std 1074 1997 IEEE Standard for Developing Software Life Cycle Processes TEEE Std 1233 1998 Edition IEEE Guide for Developing System Requirements Specifications 1 ASTM publications are available from the American Society for Testing and Materials 100 Barr Harbor Drive West Conshohocken PA 19428 2959 USA publications are available from the Institute of Electrical and Electronics Engineers 445 Hoes Lane Box 1331 Piscataway NJ 08855 1331 USA 3As this standard goes to press IEEE Std 828 1998 IEEE Std 1012a 1998 IEEE Std 1016 1998 and IEEE Std 1233 1998 Edition are approved but not yet published The draft standards are however available from the IEEE Anticipated publication date is Fall 1998 Contact the IEEE Standards Dep
40. 998 IEEE All rights reserved 27 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR the term customer where IEEE EIA 12207 0 1996 uses acquirer and this recommended practice uses user where IEEE EIA 12207 0 1996 uses operator B 2 2 Process correlation TEEE EJA 12207 0 1996 uses a process oriented approach for describing the definition of a set of require ments for software This recommended practice uses a product oriented approach where the product is a Software Requirements Description SRD There are natural process steps namely the steps to create each portion of the SRD These may be correlated with the process requirements of 12207 0 1996 The difference is that this recommended practice is focused on the development of software requirements whereas 12207 0 1996 provides an overall life cycle view and mentions Software Requirements Analysis as part of its Development Process This recommended practice provides a greater level of detail on what is involved in the preparation of an SRD B 2 3 Life cycle data correlation TIEEE EIA 12207 0 1996 takes the viewpoint that the software requirements are derived from the system requirements Therefore it uses the term description rather that specification to describe the software requirements In a system in which software is a component each requiring its own specification there would be a System Requirements Specification
41. HAR 10 VARCHAR 10 VARCHAR 10 tbl_recomendaciones tbl_usuarios Codigo_Recomend VARCHAR 10 Codigo Usuario VARCHAR 10 VARCHAR 50 VARCHAR 50 VARCHAR 10 VARCHAR 10 VARCHAR 10 Codigo_Proyecto Nombres Apellidos Descripcion Fecha Hora Codigo_Usuario Login Password Codigo_Tipo Nombre_Recomend VARCHAR 6 VARCHAR 255 VARCHAR 255 VARCHAR 10 VARCHAR 10 VARCHAR 10 tbl_tipo_usuario PK Codigo Tipo VARCHAR 10 VARCHAR 50 VARCHAR 100 Nombre Nota Descripcion FK1 tbl_dispositivos VARCHAR 255 Codigo_Usuario VARCHAR 10 95 tbl_auditoria Codigo_Usuario VARCHAR 10 Codigo_Evento VARCHAR 10 Codigo_Proyecto VARCHAR 6 Fecha VARCHAR 10 Hora VARCHAR 10 tbl_ clientes Id Cliente VARCHAR 10 Nombre VARCHAR 100 Empresa VARCHAR 50 Direccion VARCHAR 100 Telefono VARCHAR 10 Celular VARCHAR 1 Ciudad VARCHAR 5 Departamento VARCHAR 5 Email VARCHAR 2 Fecha_Crea VARCHAR 1 Fecha_Modif VARCHAR 1 Hora_Modif VARCHAR 1 4 5 0 0 0 0 0 0 Usuario_Modif VARCHAR 10 tbl_proyectos_atributos Id_Atributo VARCHAR 12 Codigo_Proyecto VARCHAR 6 Codigo_Atributo VARCHAR 10 Descripcion VARCHAR 255 Fecha_Crea VARCHAR 10 Hora_Crea VARCHAR 10 Fecha_Modif VARCHAR 10 Hora_Modif VARCHAR 10 Usuario_Modif VARCHAR 10 tbl_atributos_tipos_descrip_proy Codigo_Atributo
42. L PROCESO Los datos son insertados en las tablas correspondientes en la base de datos o son actualizados si el dispositivo ya estaba registrado previamente Si los datos son ingresados de manera err nea se deben emitir los correspondientes mensajes de error 44 5 CONCLUSIONES Pese a que los problemas en la industria del software persisten no se le ha dado el lugar correspondiente a las actividades que involucra la Ingenieria de Requerimientos ni a los procesos de desarrollo de software que propone la Ingenier a del Software No es suficiente que esto procesos actividades metodolog as y est ndares existan est n ah para que esa industria que se encarga de proveer soluciones software sea responsable de su propia preparaci n y pueda enfrentar con altura la demanda del mercado que exige calidad Teniendo en cuenta la gran importancia que tiene la especificaci n de requerimientos para el desarrollo de un proyecto software este proyecto de grado tuvo como objetivo central el dise o e implementaci n de un prototipo software para la captura especificaci n y documentaci n de requerimientos de software utilizando un est ndar reconocido en el rea de la ingenier a del software Dentro de los est ndares existentes se seleccion el est ndar IEEE 830 que aunque no es recomendable para proyectos que utilicen metodolog as DRA por el trabajo detallado y responsable que implica es un est ndar que se puede adaptar f cilmente
43. MPO TIPO LONG DESCRIPCI N Id Requerimiento VARCHAR 12 Identifica un requerimiento determinado Nombre VARCHAR 50 Nombre del requerimiento Descripci n LONGCHAR Describe el requerimiento Codigo_Atributo VARCHAR 10 Identifica el atributo de un tipo de requerimiento determinado Codigo_Proyecto VARCHAR 6 C digo nico alfa num rico que representa la identificaci n de un proyecto VARCHAR 10 Fecha de creaci n del requerimiento en formato aaaa mm dd VARCHAR 10 Hora de creaci n del requerimiento en formato hh mm ss Fecha Modif VARCHAR 10 Fecha de modificaci n del requerimiento en formato aaaa mm dd Hora Modif VARCHAR 10 Hora de modificaci n del requerimiento en formato hh mm ss Usuario_Modif VARCHAR 10 Usuario que modific el requerimiento Tabla 9 Tabla Requerimientos de Proyectos Aplicaci n de escritorio Pascar 88 Nombre Tabla TIPO USUARIO Descripci n Almacena los tipos de usuarios que intervienen en el documento de especificaci n de requisitos de software del proyecto _ USUARIO LONG DESCRIPCI N Codigo Tipo VARCHAR 10 Identifica un tipo de usuario Nombre VARCHAR 50 Nombre del tipo de usuario Descripci n VARCHAR 100 Descripci n del tipo de usuario Tabla 10 Tabla Tipos de Usuarios Aplicaci n de escritorio Pascar Nombre Tabla Tbl_USUARIOS Descripci n Almacena los datos identificadores de los
44. OFTWARE PARA LA CAPTURA ESPECIFICACI N Y DOCUMENTACI N DE REQUERIMIENTOS DE SOFTWARE UTILIZANDO EL EST NDAR IEEE 830 REGISTRO No FACULTAD INGENIERIAS FISICOMECANICAS INGENIERIA DE SISTEMAS CALIFICACION CREDITOS CUATRO OCHO 4 8 8 DIRECTOR DE PROYECTO NOMBRE JOSE CARCAMO SEPULVEDA CALIFICADORES FECHA ANO MES DIA 1 AN A WILSON AN GALVIS 2006 06 21 Con todo mi cari o a mis padres Ulises y Maria Elsa a mis hermanas A R P R AGRADECI MIENTOS La autora expresa sus agradecimientos A Dios por darme la fortaleza y abrirme el camino para llegar hasta aqui A mi familia por su confianza y ayuda en especial a mi madre por su compa a comprensi n y apoyo Al profesor Jos C rcamo Sep lveda por su gran disposici n gu a y pronta colaboraci n durante el desarrollo del proyecto Al Ingeniero Edward Jos Beltr n Lozano por su atenci n orientaci n y paciencia al brindarme asesor a en el proyecto Y a todos aquellos que intervinieron en la culminaci n de este trabajo de grado muchas gracias RESUMEN TITULO PASCAR PROTOTIPO DE APLICACI N SOFTWARE PARA LA CAPTURA ESPECIFICACI N Y DOCUMENTACI N DE REQUERIMIENTOS DE SOFTWARE UTILIZANDO EL EST NDAR IEEE 830 AUTOR Adriana Roc o P rez Rojas PALABRAS CLAVE Ingenier a de Requerimientos Est ndar 1 830 Requisitos Especificaci n de Requisitos Ingenier a del Softw
45. PASCAR PROTOTIPO DE APLICACI N SOFTWARE PARA LA CAPTURA ESPECI FI CACI N Y DOCUMENTACI N DE REQUERI MIENTOS DE SOFTWARE UTILIZANDO EL EST NDAR IEEE 830 ADRIANA ROC O P REZ ROJAS UNIVERSIDAD INDUSTRIAL DE SANTANDER FACULTAD DE INGENIER AS FISICO MECANICAS ESCUELA DE INGENIER A DE SISTEMAS E INFORM TICA BUCARAMANGA 2005 PASCAR PROTOTIPO DE APLICACI N SOFTWARE PARA LA CAPTURA ESPECI FI CACI N Y DOCUMENTACI N DE REQUERI MIENTOS DE SOFTWARE UTILIZANDO EL EST NDAR IEEE 830 ADRIANA ROC O P REZ ROJAS Trabajo de grado para optar el t tulo de Ingeniera de Sistemas Director Ing JOSE CARCAMO SEPULVEDA Mag ster en Inform tica UNIVERSIDAD INDUSTRIAL DE SANTANDER FACULTAD DE INGENIER AS FISICO MECANICAS ESCUELA DE INGENIER A DE SISTEMAS E INFORM TICA BUCARAMANGA 2005 NOTA DE PROYECTO DE GRADO NOMBRE DEL ESTUDIANTE CODIGO ADRIANA ROCIO PEREZ ROJAS 1991147 TITULO DELPROYECTO PASCAR PROTOTIPO DE APLICACION SOFTWARE PARA LA CAPTURA ESPECIFICACION Y DOCUMENTACION DE REQUERIMIENTOS DE SOFTWARE UTILIZANDO EL ESTANDAR IEEE 830 CALIFICACION CREDITOS APROBADO 7 11 DIRECTOR DE PROYECTO NOMBRE JOS C RCAMO SEP LVEDA CALIFICADORES FECHA A A 224 7 A A O MES DIA FERNANDO ANTONIO ROJAS MORALES N AS 2006 06 21 NOTA DE PROYECTO DE GRADO NOMBRE DEL ESTUDIANTE CODIGO ADRIANA ROCIO PEREZ ROJAS 1991147 TITULO DELPROYECTO PASCAR PROTOTIPO DE APLICACI N S
46. R 10 Identifica el atributo de un tipo de requerimiento determinado VARCHAR 50 Nombre atributo de tipo de requerimiento Cod_Tipo VARCHAR 10 Identifica el tipo de requerimiento al que pertenece el atributo Tabla 23 Tabla Atributos de Requerimientos Aplicaci n movil Pascar e Nombre Tabla M_ REQUERIMIENTOS e Descripci n Almacena los requerimientos de cada proyecto M_ REQUERI MI ENTOS CAMPO TIPO LONG DESCRIPCI N Id _Requer VARCHAR 12 Identifica un requerimiento determinado Nombre VARCHAR 50 Nombre del requerimiento Descrip LONGCHAR Describe el requerimiento Identifica el atributo de tipo de VARCHAR 10 requerimiento determinado Nom_Atrib VARCHAR 50 Nombre del atributo de un tipo de requerimiento Cod VARCHAR 6 Identifica el proyecto al que pertenece el requerimiento Fecha Mod VARCHAR 10 Fecha de modificaci n del requerimiento en formato Z aaaa mm dd Hora Mod VARCHAR 10 Hora de modificaci n del requerimiento en formato hh mm ss Usu_Mod VARCHAR 10 Usuario que modific el requerimiento Tabla 24 Tabla Requerimientos de Proyectos Aplicaci n m vil Pascar 93 e Nombre Tabla M_AUDITORIA e Descripci n Es la bit cora de la aplicaci n donde se almacenan los cambios que un usuario ha realizado dentro de de la SRS de un proyecto M_AUDITORIA CAMPO TIPO LONG DESCRIPCI N Co
47. REQUERIMIENTOS DEL PROYECTO 1 1 Requisitos espec ficos Figura 2a Estructura Adaptada de la SRS 27 3 MARCO CONCEPTUAL En ste capitulo se describen algunos aspectos t cnicos aplicados para el desarrollo del prototipo PASCAR la plataforma utilizada y herramientas de desarrollo que se emplearon No es un cap tulo que ahonde en aspectos espec ficos si no que se escribi con la intenci n de dar una idea general de las tecnolog as involucradas 3 1 PLATAFORMA Y DISPOSITIVO UTILIZADO El dispositivo m vil elegido para el proyecto fue Pocket PC un dispositivo de bolsillo similar a un computador de escritorio pero de dimensiones reducidas y Capacidades limitadas Los Pocket PC trabajan bajo sistema operativo Windows especiales Windows CE Windows Mobile que le permiten administrar aplicaciones personales y profesionales casi como ordenador de escritorio Windows Mobile es un sistema operativo compacto dise ado para dispositivos m viles celulares PDA s similar a las versiones de escritorio de Windows de Microsoft que contiene prestaciones multimedia acceso remoto a datos e Internet Para el proyecto fue utilizada la Segunda Edici n de Windows Mobile 2003 para Pocket PC Para efectos de desarrollo se requiri el uso de un emulador para realizar las pruebas y ejecutar la aplicaci n m vil sin necesidad de un dispositivo f sico Se utiliz una aplicaci n de escritorio que emula el comportamiento de un d
48. RS eee eeceseceeceeceeesaeeeeesseesaeeeeeseseeeaeeseee 15 5 4 Supporting Information iii dd 19 Annex A informative SRS templateS oooooonnccinccnoncconccnonnconnnnnnnconcnonnnconccnnnnconncnnnncnnn cnn rra cnn nn ronca rn nn 21 Annex B informative Guidelines for compliance with IEEE EIA 12207 1 1997 27 vi Copyright O 1998 IEEE All rights reserved IEEE Recommended Practice for Software Requirements Specifications 1 Overview This recommended practice describes recommended approaches for the specification of software require ments It is divided into five clauses Clause 1 explains the scope of this recommended practice Clause 2 lists the references made to other standards Clause 3 provides definitions of specific terms used Clause 4 provides background information for writing a good SRS Clause 5 discusses each of the essential parts of an SRS This recommended practice also has two annexes one which provides alternate format templates and one which provides guidelines for compliance with IEEE EIA 12207 1 1997 1 1 Scope This is a recommended practice for writing software requirements specifications It describes the content and qualities of a good software requirements specification SRS and presents several sample SRS outlines This recommended practice is aimed at specifying requirements of software to be developed but also can be applied to assist in the selection of in hous
49. SRS and one or more SRDs If the term Software Require ments Specification had been used there would be a confusion between an SRS referring to the system or software requirements In the case where there is a stand alone software system IEEE EIA 12207 1 1997 states If the software is a stand alone system then this document should be a specification B 3 Content mapping This clause provides details bearing on a claim that an SRS complying with this recommended practice would also achieve document compliance with the SRD described in IEEE EIA 12207 1 1997 The requirements for document compliance are summarized in a single row of Table 1 of IEEE EIA 12207 1 1997 That row is reproduced in Table B 1 of this recommended practice Table B 1 Summary of requirements for an SRD excerpted from Table 1 of IEEE EIA 12207 1 1997 IEEE EIA 12207 0 1996 12207 1 1997 Clause Clause Information item Software 5 1 1 4 5 3 4 1 Description i IEEE Std 830 1998 EIA IEEE Requirements 5 3 4 2 See note for 6 22 1 J STD 016 F 2 3 F 2 4 MIL Description of IEEE EIA STD 961D Also see ISO IEC 12207 1 1997 5806 5807 6593 8631 8790 and 11411 for guidance on use of notations The requirements for document compliance are discussed in the following subclauses 3 1 discusses compliance with the information requirements noted in column 2 of Table as prescribed by 5 1 1 4
50. Specific requirements 3 1 Functional requirements 3 1 1 Mode 1 3 1 1 1 External interfaces 3 1 1 1 1 User interfaces 3 1 1 1 2 Hardware interfaces 3 1 1 1 3 Software interfaces 3 1 1 1 4 Communications interfaces 3 1 1 2 Functional requirements 3 1 1 2 1 Functional requirement 1 Copyright O 1998 IEEE All rights reserved 21 IEEE Std 830 1998 3 2 3 3 3 4 IEEE RECOMMENDED PRACTICE FOR 3 1 1 2 n Functional requirement n 3 1 1 3 Performance 3 1 2 Mode 2 3 1 m Modem Design constraints Software system attributes Other requirements A 3 Template of SRS Section 3 organized by user class 3 Specific requirements 3 1 3 2 3 3 3 4 3 5 3 6 External interface requirements 3 1 1 User interfaces 3 1 2 Hardware interfaces 3 1 3 Software interfaces 3 1 4 Communications interfaces Functional requirements 3 2 1 User class 1 3 2 1 1 Functional requirement 1 1 3 2 1 n Functional requirement 1 n 3 2 2 User class 2 3 2 m User class m 3 2 m 1 Functional requirement m 1 3 2 m n Functional requirement m n Performance requirements Design constraints Software system attributes Other requirements A 4 Template of SRS Section 3 organized by object 3 Specific requirements 3 1 3 2 22 External interface requirements 3 1 1 User interfaces 3 1 2 Hardware interfaces 3 1 3 Software interfaces 3 14 Communications interfaces Classes Objects 3 2 1 Class Object 1 Copyright O 1998 IEEE All rights r
51. VARCHAR 10 Nombre VARCHAR 50 Descripcion VARCHAR 100 Codigo_Tipo VARCHAR 10 tbl_tipos_descrip_proy PK Codigo Tipo VARCHAR 10 VARCHAR 50 VARCHAR 100 Nombre Descripcion 96 8 3 2 Modelo de Datos Aplicaci n M vil 5 m_clientes m_usuarios Codigo Usu VARCHAR 10 Id_ Cliente VARCHAR 10 Nombre_Usu VARCHAR 100 Nombre VARCHAR LOG Empresa VARCHAR 50 Password VARCHAR 10 A Direccion VARCHAR 100 Nombre_Dis VARCHAR 50 Nota VARCHAR 255 Telefono VARCHAR 10 Celular VARCHAR 15 Ciudad VARCHAR 50 Departamento VARCHAR 50 m_tipos_req Email VARCHAR 20 PK Cod Tipo VARCHAR 10 Nombre VARCHAR 50 m_requerimientos PK Id Requer VARCHAR 12 m_atributos_tipos_re PK Cod Atrib VARCHAR 10 Nombre VARCHAR 50 Cod_Tipo VARCHAR 10 m_proy_atributos Id_Atrib VARCHAR 12 Cod_Usua Cod_Proy Cod_Tipo Cod_Atrib VARCHAR 6 VARCHAR 10 VARCHAR 10 Nom_Atrib VARCHAR 50 Descrip VARCHAR 255 Fecha_Mod VARCHAR 10 VARCHAR 10 VARCHAR 10 m_auditoria VARCHAR 10 Cod_Evento VARCHAR 10 VARCHAR 6 Cod_Proy Fecha VARCHAR 10 Hora VARCHAR 10 97 Cod_Proy Nombre Descrip Cod_Atrib Nom_Atrib Fecha_Mod Hora_Mod Usu_Mod VARCHAR 6 VARCHAR 50 VARCHAR 255 VARCHAR 10 VARCHAR 50 VARCHAR 10 VARCHAR 10 VARCHAR 10 m_proyectos
52. Validaci n y Gesti n de Requisitos La validaci n realizada en esta parte del proceso tiene como fin verificar que los requerimientos definidos en la SRS son los que en realidad demanda el cliente Por ejemplo se debe cuestionar si todas las funciones requeridas por el cliente est n incluidas en la SRS si no existen problemas de consistencia ambig edad claridad factibilidad verificabilidad y trazabilidad La gesti n de requisitos es una actividad que se mantiene durante todo el desarrollo del proyecto y est sujeta a la volatilidad de los requerimientos Un requerimiento se transforma con el tiempo debido a cambios que ocurren en el planteamiento del problema en el ambiente en las percepciones del cliente o debido a una definici n deficiente del mismo Por esto es importante llevar un control de las versiones de los requerimientos y tener claras las dependencias y relaciones que tienen con otros requerimientos de modo que no se pierda la integridad necesaria para las etapas posteriores en el desarrollo del proyecto Podemos concluir entonces que la calidad del producto software se asegura cuando se valida la especificaci n de requisitos pactada y se revisa que los requisitos del sistema han sido establecidos sin ambiguedad ni inconsistencia y que los errores hayan sido corregidos Con la gesti n de requisitos se asegura cierto control de los requisitos y los cambios que se presenten en un momento dado 2 3 T CNICAS USADAS EN LA
53. a Versi n Dise o Global y del N cleo del Sistema Este ciclo se repite hasta agotar el tiempo el presupuesto el n mero de iteraciones planeadas o hasta que el cliente est satisfecho Incorporar la realimentaci n Desarrollar una Versi n del cliente Educir la 1 realimentaci n del cliente Figura 3 Modelo de Entrega Evolutiva 7 McCONNELL Steve Desarrollo y Gesti n de Proyectos Inform ticos Cap tulo 7 Planificaci n del Ciclo de Vida p gina 164 McGraw Hill Espa a 1997 30 4 2 FUNCIONALIDADES DE LA APLICACI N El producto desarrollado en este proyecto es un prototipo software para la captura y administraci n de requerimientos de software dise ado para reforzar las tareas de especificaci n de requisitos de un proyecto software El proyecto PASCAR cuenta con dos aplicaciones La principal que es la aplicaci n de escritorio y la secundaria que se ha dado como valor agregado al proyecto y es la aplicaci n m vil La primera cuenta con toda la independencia funcional necesaria de modo que no requiera ninguna otra aplicaci n para trabajar de manera completa de acuerdo a los objetivos propuestos para la especificaci n y administraci n de requerimientos La segunda como valor agregado es una herramienta adicional que es suministrada para permitir mayor movilidad al usuario de la aplicaci n de escritorio utilizando un PDA y permite la creaci n y actualizaci n de requerimientos d
54. a 20 2 4 3 2 1 Perspectiva del Productos idad A di 20 2 4 3 2 2 Funciones del PrOdUCTO occccccccccoccncncnncnncccnnccnnnnnnnrnnnnn 22 2 4 3 2 3 Caracter sticas del USUar O li A 22 2 4 3 2 4 Restricciones csse co conan na 22 2 4 3 2 5 Suposiciones y dependenciaS 23 2 4 3 3 Requisitos 23 2 4 3 3 1 Interfaces a a 23 23 ZA AN NN cng 24 2 4 3 3 3 Requisitos de desarrollo sidonia 24 2 4 3 3 4 Requisitos l gicos de la base de 24 2 4 3 3 5 Restricciones de dise o 2 a 24 2 4 3 3 6 Atributos del software del sistema 25 2 4 3 3 7 Organizar los requisitos espec fiCOS 25 2 4 3 4 Informaci n de APOYO A a cia 26 2 4 3 4 1 Tabla de contenidos indice 26 LAA A A A ASEOS 26 3 MAREO CONCEPTUAL a A id Rel SE 28 3 1 PLATAFORMA Y DISPOSITIVO UTILIZADO 28 3 2 HERRAMIENTAS DE 28 3 2 1 Aplic ci n M vil and IRA 28 3 2 2 Aplicacion de Escritora da 29 4 DISE O E IMPLEMENTACI N DEL
55. a los siguientes aspectos 10 e Identificar los requerimientos que se definieron de forma ambigua inconsistente e incompleta de modo que stos no ocasionen problemas m s adelante e la medida que se analice la importancia de cada requerimiento es bueno clasificarlo e identificarlo de acuerdo a la prioridad que ste tenga dentro del proyecto y el modelo del negocio del cliente e Evaluar las factibilidades de la implementaci n de los requerimientos definidos de modo que puedan satisfacerse con la tecnolog a existente que se acoplen con la operaci n del negocio con el presupuesto disponible entre otros En decir se debe realizar una organizaci n y agrupaci n de los requisitos para obtener un an lisis de cada requisito en relaci n con los dem s con las necesidades del cliente con los objetivos propuestos y con la consistencia claridad y completitud necesarias Se debe hacer una negociaci n iterativa con el cliente para poder realizar un filtrado de los requisitos pertinentes para el producto que se espera obtener de modo que se logre un beneficio mutuo 2 2 3 Especificaci n de Requisitos SRS6 En sta fase se obtiene el resultado final de las actividades de an lisis y evaluaci n de requerimientos Durante la especificaci n de requerimientos de software SRS se obtiene un documento que contiene plasmado la descripci n completa del sistema que se va a desarrollar a partir de la definici n del alcance del proy
56. abilidad al error Y nequ voco No Ambiquo Una SRS es inequ voca si y s lo si cada requisito declarado tiene s lo una interpretaci n Como m nimo se requiere que cada caracter stica de la ltima versi n del producto se describa usando un nico t rmino En casos d nde un t rmino en un contexto particular tenga significados m ltiples el t rmino debe ser incluido en un glosario d nde su significado tiene un sentido m s espec fico 15 La SRS es una parte importante del proceso de requisitos del ciclo de vida del software y se usa en el dise o aplicaci n supervisi n comprobaci n aprobaci n y pruebas como est descrito en IEEE Std 1074 1997 El SRS debe ser inequivoco para aqu llos que lo crean y para aqu llos que lo usan Sin embargo estos grupos no tienen a menudo el mismo fondo y por consiguiente no tienden a describir los requisitos del software de la misma manera Y Completo Una SRS est completa si y s lo si incluye los siguientes elementos a Todos los requisitos significativos relacionando la funcionalidad desarrollo las restricciones del dise o los atributos y las interfaces externas En particular debe reconocerse cualquier requisito externo impuesto por una especificaci n del sistema y debe tratarse b La definici n de las respuestas del software a todos los posibles datos de la entrada del sistema y a toda clase de situaciones Una nota que es importante especificar son las cont
57. adas en el formulario desplegado por el sistema que tienen que ver con la actualizaci n de un requerimiento espec fico e SALIDAS DEL PROCESO La salida que se produce est directamente ligada con la actualizaci n de los datos en la tabla correspondiente en la base de datos En caso que los datos no sean ingresados correctamente se emitir n los respectivos mensajes de error 4 4 4 Generaci n de documentaci n de Requerimientos Generar documento de SRS Usuario Aplicaci n de Escritorio Figura 7 Caso de Uso Generaci n de Documentaci n de Requerimientos 39 4 4 4 1 CASO DE USO Generar Documento de SRS DESCRIPCION En este caso de uso se permite la generaci n del documento de la especificaci n de requerimientos de software SRS de un proyecto determinado en formato RTF RESTRICCIONES Debe existir un proyecto registrado par poder generar la documentaci n PROCESO e El usuario selecciona la opci n Generar informe de SRS e El sistema valida el proyecto activo en el sistema e El sistema genera el documento de la SRS del proyecto ENTRADAS DEL PROCESO El usuario selecciona la opci n para generar el documento de SRS SALIDAS DEL PROCESO Se debe obtener un archivo donde se almacene la SRS generada 4 4 5 Sincronizaci n de datos entre las dos aplicaciones Configurar Sincronizaci n Sincronizar Dispositivos Figura 8 Caso de Uso Sincronizaci n de Datos Usuario Aplicaci n de
58. ael Alan Miller Celia H Modell James W Moore Pavol Navrat Myrna L Olson Terry Rout Richard Schmidt Norman F Schneidewind David Schultz Basil Sherlund Peter Voldner Ronald Wade Indradeb P Pal Alex Polack Peter T Poon Lawrence S Przybylski Kenneth R Ptack Annette D Reilly Dennis Rilling Andrew P Sage Helmut Sandmayr Stephen R Schach Hans Schaefer Norman Schneidewind David J Schultz Lisa A Selmon Robert W Shillato David M Siefert Carl A Singer James M Sivak Richard S Sky Nancy M Smith Melford E Smyre Harry M Sneed Alfred R Sorkowitz Donald W Sova Luca Spotorno Julia Stesney Fred J Strauss Christine Brown Strysik Toru Takeshita Richard H Thayer Booker Thomas Patricia Trellue Theodore J Urbanowicz Glenn D Venables Udo Voges David D Walden Dolores Wallace William M Walsh John W Walz Camille SWhite Partain Scott A Whitmire P A Wolfgang Paul R Work Natalie C Yopconka Janusz Zalewski Geraldine Zimmerman Peter F Zoll Copyright 1998 IEEE All rights reserved When the IEEE SA Standards Board approved this recommended practice 25 June 1998 it had the fol lowing membership Richard J Holleman Chair Donald N Heirman Vice Chair Judith Gorman Secretary Satish K Aggarwal James H Gurney L Bruce McClung Clyde R Camp Jim D Isaak Louis Fran ois Pau James T Carlo Lowell G Johnson Ronald C Petersen Gary R Engmann Robert Kennelly Gerald H P
59. are DESCRIPCION La Ingenier a del Software se ha encargado de brindar metodolog as y est ndares para mejorar el proceso de desarrollo del software Existen productos software en el mercado que han adaptado algunas de stas metodolog as para intervenir en el proceso del ciclo de vida del software y apoyar la industria del software pero a n existen muchos problemas relacionados con el desarrollo de soluciones software porque muchas de las empresas que pertenecen a sta industria desconocen esos procesos o no est n en la capacidad de adquirir las soluciones del mercado desarrollando sus productos de manera artesanal o inadecuada PASCAR es un prototipo software que utiliza como gu a el est ndar IEEE 830 y ha sido planteado como herramienta alternativa para ser utilizada en las actividades de la Ingenier a de Requerimientos ayudando a la gesti n de requisitos dentro de un proyecto software Este proyecto consta de dos aplicaciones un prototipo de escritorio que facilita la captura y administraci n de requerimientos para la generaci n del documento de Especificaci n de Requisitos de Software SRS y un prototipo m vil que puede utilizarse como herramienta auxiliar para capturar y administrar los requerimientos de software en un dispositivo m vil Pocket PC desde el lugar que lo necesite el primero es independiente del segundo pero se ha adicionado ste segundo prototipo al proyecto como valor agregado para darle al prototipo co
60. arson Education M xico 2002 MOORE James W Software Engineering Standards A User s Road Map IEEE Computer Society Unites States 2000 m McCONNELL Steve Desarrollo y gesti n de proyectos inform ticos McGraw Hill Espa a 1997 Software Engineering Standards Committee of the IEEE Computer Society IEEE Std 830 1998 IEEE Recommended Practice for Software Requirements Specifications The Institute of Electrical and Electronics Engineers Inc United States 1998 Software Engineering Standards Committee of the IEEE Computer Society IEEE Std 1074 1997 IEEE Standard for Developing Software Life Cycle Processes The Institute of Electrical and Electronics Engineers Inc United States 1998 ZAPATA J Carlos M ARANGO ISAZA J Fernando Alineaci n entre Metas Organizacionales y Elicitaci n de Requisitos del Software Dyna A o 71 Nro 143 pags 101 110 Medell n Noviembre de 2004 m ADIBOWO Sasmito RAMBUTAN Requirements management tool for busy systems analysts Faculty of Computer Science University of Indonesia 2003 IRgA 2 0 El Control de sus Especificaciones TCP Sistemas e Ingenier a Abril de 2002 m P REZ ROJAS Adriana Roc o Plan de Proyecto de Grado PASCAR Universidad Industrial de Santander Facultad de Ingenier as F sico Mec nicas Escuela de Ingenier a de Sistemas Noviembre de 2005 47 8 5 8 1 ESTANDAR IEEE 830 El estandar IEEE 830 1998 IEEE Recommended
61. artment at 1 732 562 3800 for status information 4See Footnote 3 gt See Footnote 3 Upon approval of IEEE P1058 by the IEEE SA Standards Board this standard will be integrated with IEEE Std 1058a 1998 and ublished as IEEE Std 1058 1998 Edition Approval is expected 8 December 1998 As this standard goes to press IEEE Std 1058a 1998 is approved but not yet published The draft standard is however available from the IEEE Anticipated publication date is December 1998 Contact the IEEE Standards Department at 732 562 3800 for status information See Footnote 6 8See Footnote 3 2 Copyright 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 3 Definitions In general the definitions of terms used in this recommended practice conform to the definitions provided in IEEE Std 610 12 1990 The definitions below are key terms as they are used in this recommended practice 3 1 contract A legally binding document agreed upon by the customer and supplier This includes the tech nical and organizational requirements cost and schedule for a product A contract may also contain infor mal but useful information such as the commitments or expectations of the parties involved 3 2 customer The person or persons who pay for the product and usually but not necessarily decide the requirements In the context of this recommended practice the customer and the supplier may be members of the same organiza
62. ations e g signal timing requirements c Interfaces to other applications d Parallel operation e Audit functions f Control functions g Higher order language requirements h Signal handshake protocols e g XON XOFF ACK NACK i Reliability requirements j Criticality of the application k Safety and security considerations 5 2 5 Assumptions and dependencies 2 5 of the SRS This subsection of the SRS should list each of the factors that affect the requirements stated in the SRS These factors are not design constraints on the software but are rather any changes to them that can affect the requirements in the SRS For example an assumption may be that a specific operating system will be available on the hardware designated for the software product If in fact the operating system is not avail able the SRS would then have to change accordingly 5 2 6 Apportioning of requirements 2 6 of the SRS This subsection of the SRS should identify requirements that may be delayed until future versions of the system 5 3 Specific requirements Section 3 of the SRS This section of the SRS should contain all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements and testers to test that the system satisfies those requirements Throughout this section every stated requirement should be externally perceivable by users operators or other external
63. ce processing activity Such traces are needed for some applications to meet minimum regulatory or financial standards An audit trace requirement may for example state that all changes to a payroll database must be recorded in a trace file with before and after values 5 3 6 Software system attributes There are a number of attributes of software that can serve as requirements It is important that required attributes be specified so that their achievement can be objectively verified Subclauses 5 3 6 1 through 5 3 6 5 provide a partial list of examples Copyright 1998 IEEE All rights reserved 17 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR 5 3 6 1 Reliability This should specify the factors required to establish the required reliability of the software system at time of delivery 5 3 6 2 Availability This should specify the factors required to guarantee a defined availability level for the entire system such as checkpoint recovery and restart 5 3 6 3 Security This should specify the factors that protect the software from accidental or malicious access use modifica tion destruction or disclosure Specific requirements in this area could include the need to a Utilize certain cryptographical techniques b Keep specific log or history data sets c Assign certain functions to different modules d Restrict communications between some areas of the program e Check data integrity for critical variables 5 3 6
64. cos seleccionado PASCAR v1 0 Yy 4 12 08 Informaci n de Cliente Proyecto Aplicacion Incusan NIT 8025456 Nombre Rupertino Garay Empresa Direcci n Tel fono M vil Ciudad Departamento Emai b del cliente del proyecto v Opci n Todos Permite listar todos los proyectos disponibles en el dispositivo v Opci n Ir a Proyecto Permite ingresar a la interfaz de atributos y requerimientos del proyecto seleccionado 112 v Opci n podemos vio 49 741212 ok Proyecto Aplicacion Incusan Atributos Requerimientos Introduccion Referencias Alcance Definici n Definiciones Acr nimos y Introducci n Referencias Resumen 3 Registros Nuevo Atributo Nuevo requerimiento seleccionar Nuevo Atributo Nuevo En esta interfaz Requerimiento dependiendo de la opci n que se haya seleccionado antes para agregar nuevos atributos o requerimientos al proyecto en caso de ser necesario PASCAR v1 0 A AN ok Proyecto Tipo de Atributo Introducci n y Atributo Objetivos v Descripci n Desarrollar un modulo para el control de inventarios que pueda ser consultado via we Ej Los botones que tienen la etiqueta Volver retornan la aplicaci n a la interfaz anterior v Opci n Salir Para salir de la aplicaci n se debe seleccionar la opci n Salir que se encuentra en la inte
65. cripci n Almacena los tipos de descripci n que se utilizan para detallar un proyecto M_TIPOS_DESCRIP_PROY CAMPO TIPO LONG DESCRIPCI N Cod_Tipo VARCHAR 10 Identifica un tipo de descripci n de un proyecto Nombre VARCHAR 50 Nombre del tipo de descripci n Tabla 18 Tabla Tipos de Atributos Aplicaci n m vil Pascar 91 Nombre Tabla M_ATRIBUTOS_TIPOS_DE M_ATRIBUTOS_TIPOS_DESCRIP_PROY Descripci n Almacena los atributos correspondientes a un tipo de descripci n de proyectos M_ATRIBUTOS TIPOS DE CAMPO TIPO LONG DESCRIPCI N Cod Atrib VARCHAR 10 Identifica el atributo que pertenece a un tipo de E descripci n de un proyecto Nombre VARCHAR 50 Nombre del atributo Cod_Tipo VARCHAR 10 Identifica a que tipo de descripci n pertenece el atributo Tabla 19 Tabla Atributos de Tipos de Atributos Aplicaci n m vil Pascar Nombre Tabla M_PROY_ATRIBUTOS M_PROYECTOS_ATRIBUTOS Descripci n Almacena la descripci n de un atributo perteneciente a un proyecto M_PROY_ATRIBUTOS CAMPO TIPO LONG DESCRIPCI N Id Atrib VARCHAR 12 Identificador nico del atributo dentro de un proyecto determinado C digo nico alfa num rico que representa VARCHAR la identificaci n de un proyecto Cod Atrib VARCHAR 10 Identifica el atributo que pertenece a un E tipo de descripci n de un proyecto Nom _ Atrib VARCHAR 50 Nombre del atributo Descri
66. ct specifications 3 2 3 1 Construct 1 3 2 3 1 1 Record type 3 2 3 1 2 Constituent fields 3 2 3 2 Construct 2 3 2 3 2 1 Record type 3 2 3 2 2 Constituent fields 3 2 3 p Construct p 3 2 3 p 1 Record type 3 2 3 p 2 Constituent fields 3 24 Data dictionary 3 2 4 1 Data element 1 3 2 4 1 1 Name 3 2 4 1 2 Representation 3 2 4 1 3 Units Format 3 2 4 1 4 Precision Accuracy 3 2 4 1 5 Range 3 2 4 2 Data element 2 3 2 4 2 1 Name 3 2 4 2 2 Representation 3 2 4 2 3 Units Format 3 2 4 2 4 Precision Accuracy 3 2 4 2 5 Range 3 2 4 4 Data element q 3 2 4 q 1 Name 3 2 4 q 2 Representation 3 2 4 4 3 Units Format 3 2 4 q 4 Precision Accuracy 3 2 4 q 5 Range Copyright O 1998 IEEE All rights reserved 25 IEEE Std 830 1998 3 3 3 4 3 5 3 6 IEEE RECOMMENDED PRACTICE FOR Performance requirements Design constraints Software system attributes Other requirements A 8 Template of SRS Section 3 showing multiple organizations 3 Specific requirements 3 1 3 2 3 3 3 4 3 5 3 6 26 External interface requirements 3 1 1 User interfaces 3 1 2 Hardware interfaces 3 1 3 Software interfaces 3 14 Communications interfaces Functional requirements 3 2 1 User class 1 3 2 1 1 Feature 1 1 3 2 1 1 1 Introduction Purpose of feature 3 2 1 1 2 Stimulus Response sequence 3 2 1 1 3 Associated functional requirements 3 2 1 2 Feature 1 2 3 2 1 2 1 Introduction Purpose of feature 3 2 1 2 2 Stimulus Response sequence 3 2 1 2 3 Associated fu
67. cto VARCHAR la identificaci n de un proyecto Nombre VARCHAR 100 Nombre del proyecto Fecha de creaci n del proyecto en formato Fecha_Creacion VARCHAR 10 Jaaa mm dd Creacion VARCHAR 10 Hora de creaci n del proyecto en formato hh mm ss Id Cliente VARCHAR 10 Identifica el cliente del proyecto software Fecha Modif VARCHAR 10 Fecha de modificaci n de los datos del Hora Modif VARCHAR 10 Hora de modificaci n de los datos del proyecto C digo del Usuario que modific los datos Usuario_ Modif VARCHAR 10 del proyecto Tabla 5 Tabla Proyectos Aplicaci n de escritorio Pascar Nombre Tabla Tbl_PROYECTOS_ ATRIBUTOS Descripci n Almacena la descripci n de un atributo perteneciente a un proyecto Tbl_PROYECTOS_ ATRIBUTOS CAMPO TIPO LONG DESCRIPCI N Id Atributo VARCHAR 12 Identificador nico del atributo dentro de un proyecto determinado C digo Unico alfa num rico que representa la Codigos Proyecto VARCHAR identificaci n de un proyecto 7 Identifica el atributo que pertenece a un tipo Codigo_Atributo VARCHAR 10 de descripci n de un proyecto Descripci n LONGCHAR Descripci n del proyecto en funci n del atributo seleccionado Fecha_Crea VARCHAR 10 Fecha de creaci n del atributo del proyecto Hora_Crea VARCHAR 10 Hora de creaci n del atributo del proyecto Fecha Modif VARCHAR 10 Fecha de modificaci n del atributo del proyecto Hora_Modif
68. customer and the supplier about contractual matters pertaining to production of software and thus should not be included in the SRS These normally include items such as a Cost b Delivery schedules c Reporting procedures d Software development methods e Quality assurance f Validation and verification criteria g Acceptance procedures Project requirements are specified in other documents typically in a software development plan a software quality assurance plan or a statement of work 5 The parts of an SRS This clause discusses each of the essential parts of the SRS These parts are arranged in Figure in an outline that can serve as an example for writing an SRS While an SRS does not have to follow this outline or use the names given here for its parts a good SRS should include all the information discussed here 10 Copyright 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 Table of Contents 1 Introduction 1 1 Purpose 1 2 Scope 1 3 Definitions acronyms and abbreviations 1 4 References 1 5 Overview Overall description 2 1 Product perspective 2 2 Product functions 2 3 User characteristics 2 4 Constraints 2 5 Assumptions and dependencies Specific requirements See 5 3 1 through 5 3 8 for explanations of possible specific requirements See also Annex A for several different ways of organizing this section of the SRS Appendixes Index Figure 1
69. d Usu VARCHAR 10 C digo para identificar el usuario que ha realizado los cambios Cod_Evento VARCHAR 10 ee del evento que se genera al realizar un Fecha VARCHAR 10 Fecha en la cual se realiza un cambio dentro de la especificaci n de req del proyecto Hora VARCHAR 10 Hora en la cual se realiza el cambio Cod_Proy VARCHAR 6 Codigo del proyecto al cual se realiza el cambio en la especificaci n de req del software Tabla 25 Tabla Auditoria Aplicaci n m vil Pascar 94 8 3 MODELO DE DATOS 8 3 1 tbl_tipos_req tbl_requerimientos Modelo de Datos Aplicaci n de Escritorio PK Id_Requerimiento PK Codigo Tipo VARCHAR 10 Nombre VARCHAR 50 Descripcion VARCHAR 100 2 Codigo Proyecto Nombre Descripcion Codigo_Atributo Fecha_Crea Hora_Crea Fecha_Modif Hora_Modif Usuario_Modif tbl_atributos_tipos_req Codigo Atributo VARCHAR 10 VARCHAR 12 VARCHAR 6 VARCHAR 50 VARCHAR 255 VARCHAR 10 VARCHAR 10 VARCHAR 10 VARCHAR 10 VARCHAR 10 VARCHAR 10 Nombre Descripcion Codigo_Tipo VARCHAR 50 VARCHAR 100 VARCHAR 10 1 Id_Cliente Nombre Fecha_Creacion Hora_Creacion Fecha_Modif Hora_Modif Usuario_Modif tbl_proyectos_usuarios VARCHAR 6 VARCHAR 10 Codigo_Proyecto Codigo_Usuario tol_proyectos PK Codigo_Proyecto VARCHAR 6 VARCHAR 10 VARCHAR 100 VARCHAR 10 VARCHAR 10 VARC
70. da utilizarse a la par con otras herramientas que den soporte a las tareas de dise o de un modo m s formal y organizado 1 4 IMPACTO En el mbito cient fico se pretende e Fomentar el formalismo en la especificaci n de requerimientos de software utilizando un est ndar de aceptaci n internacional como es el Std IEEE 830 a trav s del desarrollo de una herramienta que sirva como gu a para la documentaci n de requisitos e Incentivar la l nea de investigaci n en Ingenier a del Software en busca de mejorar los procesos utilizados en las fases de desarrollo del software y en este caso la especificaci n de requisitos as mismo la mejora de otros procesos que propendan por la obtenci n de productos software de mayor calidad En el ambito social se pretende Orientar las actividades realizadas por los analistas de sistemas en el proceso de captura especificaci n gesti n y documentaci n de requerimientos de software con el uso de una aplicaci n software que le permita administrar los diferentes proyectos de desarrollo de software que tenga a su cargo de una manera m s organizada Proveer a los clientes de productos software medios de verificaci n de sus especificaciones a trav s de la documentaci n de requerimientos de software de modo que puedan corregir a tiempo las inconsistencias que se presenten As el producto software se acercar m s a lo que el cliente necesita proporcion ndole una mayor sat
71. dbook To the customers suppliers and other individuals a good SRS should provide several specific benefits such as the following Establish the basis for agreement between the customers and the suppliers on what the software product is to do The complete description of the functions to be performed by the software specified in the SRS will assist the potential users to determine if the software specified meets their needs or how the software must be modified to meet their needs Reduce the development effort The preparation of the SRS forces the various concerned groups in the customer s organization to consider rigorously all of the requirements before design begins and reduces later redesign recoding and retesting Careful review of the requirements in the SRS can reveal omissions misunderstandings and inconsistencies early in the development cycle when these problems are easier to correct Provide a basis for estimating costs and schedules The description of the product to be developed as given in the SRS is a realistic basis for estimating project costs and can be used to obtain approval for bids or price estimates Provide a baseline for validation and verification Organizations can develop their validation and verification plans much more productively from a good SRS As a part of the development contract the SRS provides a baseline against which compliance can be measured Facilitate transfer The SRS ma
72. dministrativas de mantenimiento o ingeniero de desarrollo el cual solo puede acceder al modulo de recomendaciones Las opciones de men son las siguientes 98 gt 1 0 Archivo Administraci n Proyectos Herramientas Windows Mobile Ayuda Men Principal Administrador del Sistema Administrador 2006 05 13 Menu Archivo Nuevo Proyecto Abrir Proyecto Cerrar Sesi n Salir Men Administraci n Tipos de Atributos Atributos Tipos de Requerimientos Atributos de Tipos de Requerimientos Usuarios Clientes Dispositivos Men Proyectos Atributos del Proyecto Requerimientos del Proyecto Men Herramientas Generar Informe SRS Recomendaciones Men Windows Mobile Sincronizador de Dispositivos Men Ayuda Manual Aplicaci n M vil 99 Manual de Escritorio Acerca de 8 4 1 2 1 Mend Archivo v Nuevo Proyecto Esta opci n permite la creaci n de un proyecto para empezar a realizar la especificaci n de requerimientos del mismo Antes de elegir esta opci n el cliente correspondiente al proyecto debe estar creado Nuevo Proyecto Crear Datos Generales C digo Nombre 003 Sistema para el manejo de personal de Empaques del Oriente 5 4 Cliente 2 Lorenzo Casta o Empaques del oriente y Fecha Creaci n Hora Creaci n Cliente P 0003 Sistema para el manejo de personal de Er 2006 05 13 22 54 51 Lorenzo Castafio Empaque
73. dos de desarrollo de Software e Aseguramiento de la Calidad e Criterios de validaci n y aprobaci n e Procedimientos de aceptaci n 2 4 3 Las partes de una SRS A continuaci n se describe una estructura para realizar una SRS Una SRS no tiene que seguir este modelo o usar los nombres dados aqu para sus partes pero s una buena SRS debe incluir toda la informaci n que se describe aqu Tabla de Contenido 1 Introducci n 1 1 Prop sito 1 2 Alcance 1 3 Definiciones siglas y abreviaciones 1 4 Referencias 1 5 Apreciaci n global 2 Descripci n global Perspectiva del producto Funciones del producto Caracter sticas del usuario Restricciones Suposiciones y dependencias 3 Requisitos espec ficos Ap ndices ndice NNNNN PA Figura 2 Estructura de la SRS 2 4 3 1 Introducci n La introducci n de la SRS debe proporcionar una apreciaci n global de la SRS completa Debe contener las siguientes subdivisiones 2 4 3 1 1 Prop sito Esta subdivisi n debe a Delimitar el prop sito de la SRS b Especificar a que p blico va dirigida la SRS 2 4 3 1 2 Alcance Esta subdivisi n debe a Identificar por el nombre el los producto s software a desarrollar por ejemplo Host DBMS Generador de Reportes etc b Explicar lo que el los producto s software har 19 Describir la aplicaci n software especific ndo los beneficios pertinentes objetivos y metas d Ser consistente con la
74. e 5 1 1 Purpose Describe a planned or actual function design performance or process An SRD complying with this recommended practice would achieve the stated purpose Any description or specification complying with IEEE EIA 12207 1 1997 shall satisfy the generic content requirements provided in 5 1 2 of that standard Table B 2 of this recommended practice lists the generic content items and where appropriate references the clause of this recommended practice that requires the same information Table B 2 Coverage of generic description requirements by IEEE Std 830 1998 TEEE EIA 12207 1 1997 generic content a Date of issue and status Corresponding clauses of TEEE Std 830 1998 Additions to requirements of TEEE Std 830 1998 Date of issue and status shall be provided b Scope 5 1 1 Scope c Issuing organization Issuing organization shall be identified d References 5 1 4 References e Context 5 1 2 Scope f Notation for description 4 3 Characteristics of a good SRS g Body 5 The parts of an SRS h Summary 5 1 1 Overview i Glossary 5 1 3 Definitions j Change history Copyright 1998 IEEE All rights reserved Change history for the SRD shall be provided or referenced 29 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR B 3 3 Compliance with specific content requirements of IEEE EIA 12207 1 1997 The specific content requirements f
75. e and commercial software products However application to already developed software could be counterproductive When software is embedded in some larger system such as medical equipment then issues beyond those identified in this recommended practice may have to be addressed This recommended practice describes the process of creating a product and the content of the product The product is an SRS This recommended practice can be used to create such an SRS directly or can be used as a model for a more specific standard This recommended practice does not identify any specific method nomenclature or tool for preparing an SRS Copyright 1998 IEEE All rights reserved 1 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR 2 References This recommended practice shall be used in conjunction with the following publications ASTM E1340 96 Standard Guide for Rapid Prototyping of Computerized Systems IEEE Std 610 12 1990 IEEE Standard Glossary of Software Engineering Terminology TEEE Std 730 1998 IEEE Standard for Software Quality Assurance Plans TEEE Std 730 1 1995 IEEE Guide for Software Quality Assurance Planning TEEE Std 828 1998 IEEE Standard for Software Configuration Management Plans IEEE Std 982 1 1988 IEEE Standard Dictionary of Measures to Produce Reliable Software TEEE Std 982 2 1988 IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reli able Software TEEE Std 1002 1987 Reaff 1
76. e del trabajo puede perjudicar tanto el resultado final si es realizada en forma err nea Ninguna otra parte es tan dificultosa de rectificar posteriormente Conforme a esto se reitera que la parte m s importante para la definici n y desarrollo de un proyecto software es la especificaci n de requerimientos de manera que se pueda realizar la trazabilidad de los mismos hasta las pruebas finales y puesta en marcha del desarrollo realizado En cuanto a ste proyecto se refiere encontramos dentro de la ingenier a del software una disciplina que se ha desarrollado para cubrir las fases iniciales del ciclo de vida del software la ingenier a de requisitos que involucra todas las actividades t cnicas y metodolog as aplicadas a la definici n y especificaci n de las necesidades de los clientes de un proyecto software La ingenier a de requisitos se ha encargado de crear mecanismos que ayuden a la especificaci n validaci n y gesti n de requisitos de software para que stos puedan convertirse en sistemas que operen como el cliente precisa Se necesita entonces una buena especificaci n de requisitos ya que sta es la que determina que har el sistema a desarrollar qu restricciones se deben tener en cuenta en el dise o y de ello depende la satisfacci n del usuario final Roger Pressman hace referencia al proceso de la ingenier a de requisitos que puede describirse seg n lan Sommerville en los siguientes pasos 3 IR Ingenie
77. e describir el sistema de acuerdo a las funciones que ofrece a su entorno desde el punto de vista del usuario y de los servicios que ofrece a ste teniendo en cuenta que el usuario no solo es una persona sino que tambi n puede ser otro sistema o una m quina e Proceso de an lisis jer rquico Facilita la organizaci n jer rquica de los requerimientos teniendo en cuenta su importancia y a identificar conflictos entre unos y otros requerimientos Es apropiada cuando la cantidad de requerimientos que se maneja dentro de un proyecto no es muy grande Algunas de estas t cnicas pueden utilizarse juntas y puede buscarse la manera de combinarlas y coordinarlas de modo que favorezcan el proceso de especificaci n de requerimientos de un proyecto software de modo particular 2 4 EST NDAR IEEE 830 PR CTICA RECOMENDADA PARA LA ESPECIFICACI N DE REQUERIMIENTOS DE SOFTWARE Un est ndar que enuncia una serie de recomendaciones para la especificaci n de requisitos de software es el Est ndar IEEE 830 IEEE Recommended Practice for Software Requirements Specifications que permite realizar una especificaci n de calidad donde el resultado obtenido del proceso de especificaci n de requerimientos de software es un documento de especificaci n que pretende ser completo y sin ambig edad Aunque ste est ndar es muy general se puede adaptar y redefinir para ser utilizado de modo m s ajustado a las necesidades particulares de una organizaci
78. e form of a proposed change of text together with appropriate supporting comments Interpretations Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications When the need for interpretations is brought to the attention of IEEE the Institute will initiate action to prepare appropriate responses Since IEEE Standards rep resent a consensus of all concerned interests it is important to ensure that any interpretation has also received the concurrence of a balance of interests For this reason IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration Comments on standards and requests for interpretations should be addressed to Secretary IEEE SA Standards Board 445 Hoes Lane P O Box 1331 Piscataway NJ 08855 1331 USA Note Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights By publication of this standard no position is taken with respect to the existence or validity of any patent rights in connection therewith The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its
79. e sometimes identified under a separate section entitled Capacity Dynamic numerical requirements may include for example the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions All of these requirements should be stated in measurable terms For example 95 of the transactions shall be processed in less than I s rather than An operator shall not have to wait for the transaction to complete NOTE Numerical limits applied to one specific function are normally specified as part of the processing subparagraph description of that function 5 3 4 Logical database requirements This should specify the logical requirements for any information that is to be placed into a database This may include the following a Types of information used by various functions b Frequency of use c Accessing capabilities d Data entities and their relationships e Integrity constraints f Data retention requirements 5 3 5 Design constraints This should specify design constraints that can be imposed by other standards hardware limitations etc 5 3 5 1 Standards compliance This subsection should specify the requirements derived from existing standards or regulations They may include the following a Report format b Data naming c Accounting procedures d Audit tracing For example this could specify the requirement for software to tra
80. e with the objectives provided in Annex H of IEEE EJA 12207 0 1996 B 4 Conclusion The analysis suggests that any SRS complying with this recommended practice and the additions shown in Table B 2 and Table B 3 also complies with the requirements of an SRD in IEEE EIA 12207 1 1997 In addition to comply with IEEE EIA 12207 1 1997 an SRS shall support the life cycle data objectives of Annex H of IEEE EIA 12207 0 1996 Copyright O 1998 IEEE All rights reserved 31 8 2 DICCIONARIO DE DATOS 8 2 1 Diccionario de Datos Aplicaci n de Escritorio e Nombre Tabla Tbl_ CLIENTES e Descripci n Almacena los datos identificadores de los clientes CLIENTES CAMPO TIPO LONG DESCRIPCI N Id Cliente VARCHAR 10 Identificador nico para el cliente Nombre VARCHAR 100 Nombre completo del cliente o representante de la empresa Empresa VARCHAR 50 Nombre de la Empresa del cliente Direccion VARCHAR 100 Direcci n principal de la empresa cliente Telefono VARCHAR 10 Tel fono del cliente Celular VARCHAR 15 Tel fono m vil del cliente Ciudad VARCHAR 50 Ciudad de residencia del cliente Departamento VARCHAR 50 Departamento de residencia del cliente Email VARCHAR 20 Correo electr nico del cliente _ VARCHAR 10 Fecha de creaci n del cliente Fecha Modif VARCHAR 10 Fecha de modificaci n del cliente Hora_Modif VARCHAR 10 Hora de modificaci n del cliente Usuario_Modif VARCHAR 10 C digo del Usuario
81. ecto las funcionalidades del sistema los requerimientos de hardware software interfaces entre otros sta especificaci n se utiliza en las fases de dise o construcci n y pruebas del software y es utilizado como parte del contrato y medio de comunicaci n entre todas las partes involucradas durante el desarrollo del proyecto software Para el cliente esta documentaci n describe sus necesidades para el equipo de desarrollo indica qu es lo que debe elaborarse para el gerente de proyecto es una medida de control y avance del sistema y para el equipo de pruebas la base de la calidad del sistema desarrollado Resumiendo es en ste paso donde se obtiene el producto final del an lisis de requisitos que realiza el ingeniero de sistemas o ing de requisitos Puede obtenerse como resultado un documento escrito combinado con modelos gr ficos y o matem ticos que describa las funciones y caracter sticas del producto software a desarrollar manteniendo las caracter sticas de 6 SRS Especificaci n de Requerimientos de software 11 consistencia verificabilidad factibilidad no ambigtedad trazabilidad precisi n 2 2 4 Modelado del Sistema En este paso se eval an los componentes del sistema y sus relaciones c mo se reflejan los requisitos y c mo se ha concebido est ticamente el sistema teniendo en cuenta que deben ser representados desde la perspectiva del cliente y c mo ste percibe sus necesidades 2 2 5
82. ectos software que parten de una mala especificaci n de requerimientos y se propone un prototipo software que toma como base un est ndar que promueve la Ingenier a del Software el est ndar IEEE 830 para la especificaci n de requerimientos de software como una manera de propender por la difusi n de procesos de desarrollo que mejoren la elaboraci n de productos en la industria del software El informe de ste proyecto se encuentra organizado por cap tulos de la siguiente manera en el primer cap tulo se encuentra la definici n del problema los objetivos propuestos el alcance e impacto del proyecto en el segundo cap tulo se encuentra el marco te rico del proyecto que incluye un apartado sobre Ingenier a del Software otro de Ingenier a de Requisitos y para finalizar la descripci n del est ndar IEEE 830 utilizado en el proyecto el tercer cap tulo es un apartado muy breve que contiene los aspectos t cnicos involucrados en el proyecto en el cuarto cap tulo se encuentra el dise o y la metodolog a aplicada al proyecto y la funcionalidad del prototipo en el quinto cap tulo se encuentran las conclusiones seguidas por las recomendaciones referencias bibliogr ficas y anexos 1 PLANTEAMIENTO DEL PROBLEMA En ste cap tulo se encuentra la definici n del problema del cual fue objeto ste proyecto describiendo algunos de sus s ntomas y efectos los objetivos trazados los alcances propuestos y el impacto estimado para el desar
83. eedor pueden ser miembros de la misma organizaci n e Proveedor La persona que producen un producto para un cliente e Usuario Es la persona que opera o act a rec proca y directamente con el producto El usuario y el cliente no son a menudo la misma persona 2 4 2 Consideraciones para producir una buena SRS Estas cl usulas proporcionan informaci n a fondo que deben ser consideradas al momento de producir una SRS Esto incluye lo siguiente 2 4 2 1 La Naturaleza de la SRS La SRS son especificaciones para un producto software en particular programa o juego de programas que realizan ciertas funciones en un ambiente espec fico La SRS puede escribirse por uno o m s representantes del proveedor uno o m s representantes del cliente o por ambos recomendado Los problemas b sicos que se presentan al escribir una SRS van dirigidos a lo siguiente 14 a La Funcionalidad Qu se supone va hacer el software b Las interfaces Externas C mo el software interact a con las personas el hardware del sistema otro hardware y otro software El Rendimiento Cu l es la velocidad la disponibilidad tiempo de respuesta tiempo de recuperaci n de varias funciones del software etc d Los Atributos Cu les son las consideraciones de portabilidad exactitud el mantenimiento seguridad etc e Las restricciones del dise o impuestas para la implementaci n Hay alg n requerimiento Standard idioma de aplicaci n
84. ent n User maintenance requirements Corresponding clauses of IEEE Std 830 1998 5 3 6 4 Maintainability Additions to requirements of IEEE Std 830 1998 Software quality characteristics 5 3 6 Software system attributes p Design and implementation constraints 5 2 4 Constraints q Computer resource requirements 5 3 3 Performance requirements Computer resource requirements r Packaging requirements Packaging requirements s Precedence and criticality of requirements 5 2 6 Apportioning of requirements t Requirements traceability 4 3 8 Traceable u Rationale 5 2 5 Assumptions and dependencies Items a through f below are from 6 22 4 a Support the life cycle data objec tives of Annex H of IEEE EIA 12207 0 1996 Support the life cycle data objectives of Annex of IEEE EIA 12207 0 1996 b Describe any function using well defined notation 4 3 Characteristics of a good SRS c Define no requirements that are in conflict 4 3 Characteristics of a good SRS d User standard terminology and definitions 5 1 3 Definition e Define each unique requirement one to prevent inconsistency 4 3 Characteristics of a good SRS f Uniquely identify each require ment 4 3 Characteristics of a good SRS B 3 4 Compliance with life cycle data objectives In addition to the content requirements life cycle data shall be managed in accordanc
85. equerimientos dentro de un proyecto software Debido a las fallas e inconsistencias en el producto software se plantea la necesidad que las organizaciones que ofrecen sus servicios como desarrolladoras de ste tipo de proyectos adopten esquemas m s formales para la especificaci n de requerimientos de software en pro de mejorar la documentaci n y administraci n de requisitos y por tanto ofrecer un producto que cumpla con las expectativas del cliente Para mejorar la fase de especificaci n de requisitos se han desarrollado est ndares y paquetes software que pretenden aportar un mayor control a esta fase del ciclo de vida del software a trav s de una administraci n organizada de requerimientos que van desde su definici n clasificaci n y seguimiento hasta su actualizaci n y mantenimiento Algunas empresas desarrolladoras de software desconocen esto y llevan poco o ning n control sobre sus productos Otras crean su propios formatos de especificaci n o si pueden adquieren herramientas CASE disponibles en el mercado Dentro de las soluciones propuestas en el mercado podemos encontrar algunas como IRGA Integral Requisite Analyzer desarrollado por TCP Sistemas Ingenier a que es una herramienta CASE de Ingenier a de Requisitos especialmente dise ada para soportar las actividades realizadas en el proceso de especificaci n de sistemas ayudando a los analistas a capturar gestionar analizar los requisitos y a trazar los mismos a
86. equipo de desarrollo e Elaborar un glosario de t rminos comunes que facilite la comunicaci n entre las partes y sirva como herramienta para evitar definiciones ambiguas y que todos los interesados se entiendan con el mimo lenguaje e Definir los l mites y las restricciones de tiempo presupuesto del entorno entre otras que se deben tener en cuenta antes de la planificaci n del desarrollo del proyecto para tener un norte claro del alcance del proyecto En s ntesis en este paso los ingenieros de sistemas deben organizar una serie de reuniones o encuentros pueden utilizarse entrevistas cuestionarios encuestas u otras metodolog as para recolecci n de informaci n con los clientes usuarios involucrados con el producto software a desarrollar para definir qu es lo que se necesita obtener del producto y superando los problemas que suelen presentarse por la mala definici n del alcance del proyecto por problemas de comprensi n y volatilidad de los requerimientos a trav s del tiempo El resultado de estos encuentros debe ser una definici n clara de las necesidades del cliente los objetivos y el alcance del sistema 2 2 2 An lisis y Negociaci n de Requisitos Es necesario realizar una depuraci n de los requerimientos identificados y evaluarlos de manera objetiva de modo que se obtengan resultados factibles coherentes y completos pero aterrizados al cliente dentro de los limites establecidos En esta parte se deben tener en cuent
87. equisitos dentro de un concepto inicial del software dise o e implementaci n del prototipo inicial refinar el prototipo hasta que sea aceptable realimentaci n y completar y entregar el prototipo como producto final al cliente 3 Modelos Evolutivos Son modelos iterativos que permiten desarrollar versiones de software cada vez m s completas y funcionales Dentro de stas metodolog as podemos encontrar el Modelo Incremental que combina el modelo en cascada pura y el de construcci n de prototipos a trav s de la entrega de incrementos durante el tiempo de desarrollo del proyecto Otro modelo que se encuentra dentro de sta categor a es el Modelo en Espiral que combina la construcci n de prototipos con el modelo orientado a riesgos que proporciona el modelo lineal secuencial Se puede encontrar otra forma de clasificaci n de metodolog as y modelos para el proceso de desarrollo del software que hacen referencia a los mencionados anteriormente o son h bridos de unos y otros pero que en esencia buscan dar soporte a las actividades del ciclo de vida de desarrollo de software 2 2 INGENIER A DE REQUISITOS IR La parte m s dif cil en la construcci n de sistemas software es decidir precisamente qu construir Ninguna otra parte del trabajo conceptual es tan dificultosa como establecer los requerimientos t cnicos detallados incluyendo todas las interfaces con humanos m quinas y otros sistemas software Ninguna otra part
88. erifiable e g a clerk typist grade 4 can do function X in Z min after h of training rather than a typist can do function X This may also be specified in the Software System Attributes under a section titled Ease of Use 5 2 1 3 Hardware interfaces This should specify the logical characteristics of each interface between the software product and the hard ware components of the system This includes configuration characteristics number of ports instruction sets etc It also covers such matters as what devices are to be supported how they are to be supported and protocols For example terminal support may specify full screen support as opposed to line by line support 5 2 1 4 Software interfaces This should specify the use of other required software products e g a data management system an operat ing system or a mathematical package and interfaces with other application systems e g the linkage between an accounts receivable system and a general ledger system For each required software product the following should be provided Name Mnemonic Specification number Version number Source Copyright 1998 IEEE All rights reserved 13 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR For each interface the following should be provided Discussion of the purpose of the interfacing software as related to this software product Definition of the interface in terms of m
89. escritorio Pascar Tabla Recomendaciones Aplicaci n de escritorio Pascar Tabla Proyectos Usuarios Aplicaci n de escritorio Pascar Tabla Auditoria Aplicaci n de escritorio Pascar Tabla Usuarios Aplicaci n m vil Pascar Tabla Clientes Aplicaci n m vil Pascar Tabla Tipos de Atributos Aplicaci n m vil Pascar Tabla Atributos de Tipos de Atributos Aplicaci n m vil Pascar Tabla Atributos de Proyectos Aplicaci n m vil Pascar Tabla Proyectos Aplicaci n m vil Pascar Tabla Tipos de Requerimientos Aplicaci n m vil Pascar Tabla Atributos de Requerimientos Aplicaci n m vil Pascar Tabla Requerimientos de Proyectos Aplicaci n m vil Pascar Tabla Auditoria Aplicaci n m vil Pascar 11 Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura 1 2 2a Estructura Adaptada de la SRS Modelo de Entrega Evolutiva Caso de Uso Autenticaci n de Usuarios Caso de Uso Gesti n de Proyectos de Software Caso de Uso Gesti n de Requerimientos Caso de Uso Sincronizaci n de Datos LISTA DE FIGURAS Representaci n del prototipo PASCAR Estructura de la SRS Caso de Uso Generaci n de Documentaci n de Requerimientos __ LISTA ANEXOS ESTANDAR I BEE afai eenean i Te dea tenses Ea N citados tee 48 DICCIONARIO DE DATOS A A 86 Diccionario de Datos Aplicaci n de 86 Diccionario de Datos Aplicaci n
90. esde el dispositivo para despu s ser sincronizado con la aplicaci n de escritorio Este prototipo cuenta con las siguientes funcionalidades generales e Autenticaci n de usuarios Se utiliza para controlar el acceso a la aplicaci n tanto la m vil como la de escritorio de los usuarios registrados e Gesti n de Proyectos de Software A trav s de ste m dulo se podr n registrar los datos preliminares de un proyecto software Consta de dos m dulos uno para la administraci n de proyectos donde se crea consulta o elimina cada proyecto con su informaci n b sica el otro m dulo para la especificaci n de proyectos donde se registran aspectos generales del proyecto y requerimientos de manera poco detallada e Gesti n de Requerimientos de Software Es el n cleo de la aplicaci n Es el m dulo en el que se registrar n y actualizar n los requerimientos de cada proyecto estructurados de acuerdo a una clasificaci n por tipos de requerimientos req Funcionales de dise o entre otros e Generaci n de Documentaci n de Requerimientos Se utiliza para generar los documentos de especificaci n de requerimientos de software de cada proyecto e Sincronizaci n de datos entre las dos aplicaciones Es un m dulo dedicado a la sincronizaci n de datos entre las aplicaciones del dispositivo 31 m vil y el computador de escritorio y realizar las tareas de actualizaci n de requisitos e Mantenimiento del sistema Es el m d
91. eserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 3 3 3 4 3 5 3 6 3 2 1 1 Attributes direct or inherited 3 2 1 1 1 Attribute 1 3 2 1 1 n Attribute n 3 2 1 2 Functions services methods direct or inherited 3 2 1 2 1 Functional requirement 1 1 3 2 1 2 m Functional requirement 1 m 3 2 1 3 Messages communications received or sent 3 2 2 Class Object 2 3 2 p Class Object p Performance requirements Design constraints Software system attributes Other requirements A 5 Template of SRS Section 3 organized by feature 3 Specific requirements 3 1 3 2 3 3 3 4 3 5 3 6 External interface requirements 3 1 1 User interfaces 3 1 2 Hardware interfaces 3 1 3 Software interfaces 3 14 Communications interfaces System features 3 2 1 System Feature 1 3 2 1 1 Introduction Purpose of feature 3 2 1 2 Stimulus Response sequence 3 2 1 3 Associated functional requirements 3 2 1 3 1 Functional requirement 1 3 2 1 3 n Functional requirement n 3 2 2 System feature 2 3 2 m System feature m Performance requirements Design constraints Software system attributes Other requirements Copyright 1998 IEEE All rights reserved 23 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR A 6 Template of SRS Section 3 organized by stimulus 3 Specific requirements 3 1 External interface requirements 3 1 1 User interfaces 3 1 2 Hardware interfaces 3 1 3 Software interfaces 3 14 Communications interfaces 3
92. essage content and format It is not necessary to detail any well documented interface but a reference to the document defining the interface is required 5 2 1 5 Communications interfaces This should specify the various interfaces to communications such as local network protocols etc 5 2 1 6 Memory constraints This should specify any applicable characteristics and limits on primary and secondary memory 5 2 1 7 Operations This should specify the normal and special operations required by the user such as a The various modes of operations in the user organization e g user initiated operations b Periods of interactive operations and periods of unattended operations c Data processing support functions d Backup and recovery operations NOTE This is sometimes specified as part of the User Interfaces section 5 2 1 8 Site adaptation requirements This should a Define the requirements for any data or initialization sequences that are specific to a given site mission or operational mode e g grid values safety limits etc b Specify the site or mission related features that should be modified to adapt the software to a partic ular installation 5 2 2 Product functions 2 2 of the SRS This subsection of the SRS should provide a summary of the major functions that the software will perform For example an SRS for an accounting program may use this part to address customer account maintenance customer statement and
93. estaciones a las entradas v lidas e inv lidas a ciertos valores c Tener todas las etiquetas y referencias a todas las figuras tablas diagramas en la SRS y definici n de todas las condiciones y unidades de medida Y Consistente La consistencia se refiere a la consistencia interna Si una SRS no est de acuerdo con alg n documento del nivel superior como una especificaci n de requisitos de sistema entonces no es correcto Una SRS es internamente consistente si y s lo si ning n subconjunto de requisitos individuales genera conflicto Y Clasificado por importancia y o estabilidad Una SRS est clasificada por importancia y o estabilidad si cada requisito en ella tiene un identificador para indicar la importancia o estabilidad de ese requisito en particular Generalmente todos los requisitos que relacionan a un producto software no son igualmente importantes Algunos requisitos pueden ser esenciales sobre todo para las aplicaciones de vida cr tica mientras otros pueden ser deseables Cada requerimiento en la SRS debe identificarse para representar estas diferencias aclarar y ser expl cito Esto ocasiona que los clientes den las consideraciones muy cuidadosamente a cada requisito para que se clarifique cualquier omisi n que ellos pueden tener y que los dise adores hagan dise os correctos y pongan el mismo esfuerzo en todos los niveles del producto del software 16 v Verificable Una SRS es verificable si y s
94. eterson Harold E Epstein E G Al Kiener John B Posey Jay Forster Joseph L Koepfinger Gary S Robinson Thomas F Garrity Stephen R Lambert Hans E Weinrich Ruben D Garzon Jim Logothetis Donald W Zipse Donald C Loughry Member Emeritus Valerie E Zelenty IEEE Standards Project Editor Copyright 1998 IEEE All rights reserved Contents Ves COVE Wii Mish Rage Se ie ea a Av ste eed a he av A 1 1 22 References its yeh Gi aa ate 2 Si SDEfiMtoNSi ia i RO 2 4 Considerations for producing a good SRS wo eee eeceseesseeseceseeseceeeeseensececeseceseseseeesesseseaeeseeeaeees 3 4 1 the SRS cuina a A ae es ee eee 3 4 2 Environment of the SRS enai dived teas sde 3 4 3 Characteristics of a 800d SRS iii di oe cesses deus aval Gaeta diese 4 4 4 Jomt pr paration of the SRS tii At ede ened 8 AS SRS evolution ia A We tes odds Se ee Re a 8 ALO Prot PIMs italia 9 4 7 Embedding design in the SRS irin ee EER EE R RES 9 4 8 Embedding project requirements in the 10 5 Whe parts of an Ria a eae o N E E 10 5 1 Introduction Section 1 of the 5 11 5 2 Overall description Section 2 of the SRS ceccescesseessceeeseceseeeeeeseceeeeseceeesaeeeseeseseneseeeeseeseees 12 5 3 Specific requirements Section 3 of the S
95. etodolog a de desarrollo de software para el proyecto se analizaron los siguientes modelos espiral cascadas modificadas prototipado evolutivo entrega por etapas y entrega evolutiva ste ltimo modelo fue seleccionado como la metodolog a a utilizar en el desarrollo del proyecto por las siguientes razones e La entrega evolutiva proporciona la flexibilidad del prototipado evolutivo y las caracter sticas de planificaci n de la entrega por etapas Es decir se planifica el desarrollo de versiones durante el proyecto en las cuales se elabora un prototipo del software que es estregado al cliente para su realimentaci n Esto le brinda cierta funcionalidad al cliente antes que el prototipo sea entregado como producto final del proyecto Adem s permite refinar los requerimientos del software que pueden no haber sido definidos detalladamente al inicio del proyecto Cuando el prototipo ha sido refinado completamente se entrega como la versi n final del proyecto e Cuando se hace una inclinaci n mayor hacia la entrega por etapas se puede conocer qu es lo que se va a construir al comienzo del proyecto sin tener que ahondar en niveles detallados de especificaci n permitiendo cierta planificaci n del cronograma y presupuesto del proyecto e Seg n Steve McConnell el modelo de entrega evolutiva se representa de la siguiente manera ae preliminar de Requerimientos Entregar la Versi n Final Entregar l
96. f Requerimientos en la retenci n de datos 2 4 3 3 5 Restricciones de dise o Esto debe especificar las restricciones de dise o derivadas por otros est ndares limitaciones de hardware etc 24 2 4 3 3 6 Atributos del software del sistema Hay varios atributos del software que puede servir como requisitos Es importante que los atributos requeridos se especifiquen para que puedan verificarse objetivamente Como ejemplo se provee la siguiente lista a Fiabilidad Esto debe especificar los factores necesarios para establecer la fiabilidad requerida del sistema software al momento de la entrega b Disponibilidad Esto debe especificar los factores necesarios para garantizar un nivel de disponibilidad definido para el sistema c Seguridad Esto debe especificar los factores que protegen el software del acceso accidental o mal volo uso modificaci n destrucci n o descubrimiento Los requisitos espec ficos en esta rea podr an incluir la necesidad de que se utilice ciertas t cnicas de encriptamiento se tengan Logs de entrada o hist ricos de datos se asigne ciertas funciones a m dulos diferentes se restrinja las comunicaciones entre algunas reas del programa la integridad de datos se verifique para variables cr ticas d Mantenimiento Esto debe especificar atributos de software que se relacionan a la facilidad de mantenimiento del propio software Puede haber alg n requisito para cierta modularidad interfaces co
97. faz con la persona que debe usar el sistema Esto puede comprender una lista de lo que debe y no aparecer hacer el sistema para el usuario Un ejemplo puede ser un requisito para la opci n de mensajes de error largos o cortos Como todos estos requisitos deben ser verificables c Interfaces de hardware Esto debe especificar las caracter sticas l gicas de cada interfaz entre el producto software y los componentes del hardware del sistema Esto incluye las caracter sticas de la configuraci n el n mero de puertos conjuntos de instrucci n etc tambi n cubre qu dispositivos ser n soportados c mo ellos ser n soportados y protocolos d Interfaces de software Esto debe especificar el uso de otros productos software requeridos e interfaces con otros sistemas Para cada producto del software requerido debe proporcionarse El nombre El c digo mnemot cnico El n mero de la especificaci n El n mero de la versi n La fuente Para cada interfaz lo siguiente debe proporcionarse La discusi n del prop sito de la interfaz del software en relaci n con el producto del software La definici n de la interfaz por lo que se refiere a los mensajes contenidos y formatos No es necesario detallar cualquiera bien la documentaci n de la interfaz pero una referencia al documento que define la interfaz se requiere 21 Interfaces de comunicaciones Esto debe especificar las interfaces comunicaciones como pro
98. fiable if and only if its structure and style are such that any changes to the requirements can be made easily completely and consistently while retaining the structure and style Modifiability generally requires an SRS to a Have a coherent and easy to use organization with a table of contents an index and explicit cross referencing b Not be redundant i e the same requirement should not appear in more than one place in the SRS c Express each requirement separately rather than intermixed with other requirements Redundancy itself is not an error but it can easily lead to errors Redundancy can occasionally help to make an SRS more readable but a problem can arise when the redundant document is updated For instance a requirement may be altered in only one of the places where it appears The SRS then becomes inconsistent Whenever redundancy is necessary the SRS should include explicit cross references to make it modifiable 4 3 8 Traceable An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation The following two types of trace ability are recommended a Backward traceability i e to previous stages of development This depends upon each requirement explicitly referencing its source in earlier documents b Forward traceability i e to all documents spawned by the SRS This depends upon each re
99. ghts reserved 9 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR The SRS should specify what functions are to be performed on what data to produce what results at what location for whom The SRS should focus on the services to be performed The SRS should not normally specify design items such as the following a Partitioning the software into modules b Allocating functions to the modules c Describing the flow of information or control between modules d Choosing data structures 4 7 1 Necessary design requirements In special cases some requirements may severely restrict the design For example security or safety require ments may reflect directly into design such as the need to a Keep certain functions in separate modules b Permit only limited communication between some areas of the program c Check data integrity for critical variables Examples of valid design constraints are physical requirements performance requirements software devel opment standards and software quality assurance standards Therefore the requirements should be stated from a purely external viewpoint When using models to illus trate the requirements remember that the model only indicates the external behavior and does not specify a design 4 8 Embedding project requirements in the SRS The SRS should address the software product not the process of producing the software product Project requirements represent an understanding between the
100. hat way custom ers unfamiliar with the notations can still understand the SRS 4 3 3 Complete An SRS is complete if and only if it includes the following elements a significant requirements whether relating to functionality performance design constraints attributes or external interfaces In particular any external requirements imposed by a system speci fication should be acknowledged and treated Copyright 1998 IEEE All rights reserved 5 IEEE Std 830 1998 IEEE RECOMMENDED PRACTICE FOR b Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations Note that it is important to specify the responses to both valid and invalid input values c Full labels and references to all figures tables and diagrams in the SRS and definition of all terms and units of measure 4 3 3 1 Use of TBDs Any SRS that uses the phrase to be determined TBD is not a complete SRS The TBD is however occa sionally necessary and should be accompanied by a A description of the conditions causing the TBD e g why an answer is not known so that the situ ation can be resolved b description of what must be done to eliminate the TBD who is responsible for its elimination and by when it must be eliminated 4 3 4 Consistent Consistency refers to internal consistency If an SRS does not agree with some higher level document such as a system requirements spec
101. herramientas todas soportadas sobre un enfoque de calidad que facilita el control del desarrollo del software de manera productiva Los m todos nos ayudan a clarificar el c mo construir t cnicamente el software e implica tareas de planificaci n an lisis de requisitos dise o codificaci n pruebas y mantenimiento Las herramientas proporcionan un soporte autom tico o semi autom tico para los m todos y el proceso es la uni n de los m todos y las herramientas que facilita un desarrollo de software racional y oportuno A modo de generalizaci n se puede decir que el trabajo de la ingenier a del software se divide en tres fases que involucran m todos herramientas y procedimientos y se describen a continuaci n Fase Enfoque Descripci n Identificaci n de la informaci n que ha de ser procesada para definir Definici n Qu correctamente el sistema Definici n de requisitos del sistema del software 2 PRESSMAN Roger Ingenier a del Software un enfoque pr ctico Quinta Edici n McGraw Hill Espa a 2002 Cap tulo 2 P g 14 Definici n del dise o del software Desarrollo C mo desarrollo implementaci n pruebas del software Detecci n de errores adaptaciones a Mantenimiento Cambio 105 cambios del entorno de los requisitos del cliente Tabla 1 Fases del Trabajo de la Ingenier a del Software Esto involucra por s mismo un despliegue de metod
102. i n del cliente del proyecto software Por tanto el cliente debe estar creado previamente en el sistema 34 4 4 2 2 3 4 5 PROCESO 1 2 El usuario selecciona la Crear Proyecto El sistema despliega una interfaz para el ingreso de la informaci n requerida para un proyecto nuevo El sistema debe validar que no se encuentren vac os los campos que se consideren obligatorios Luego de ingresar la informaci n el usuario hace clic en la opci n Guardar Si la informaci n ha sido ingresada correctamente se almacena la informaci n en la base de datos NOTA El procedimiento a seguir para la modificaci n de los datos de un proyecto sigue la misma estructura y validaciones que para el caso de creaci n descrito anteriormente ENTRADAS DEL PROCESO Todas las entradas del proceso est n dadas por las solicitadas en el formulario desplegado por el sistema SALIDAS DEL PROCESO La salida que se produce est directamente ligada con la inserci n o actualizaci n de los datos en la tabla correspondiente en la base de datos En caso que los datos no sean ingresados correctamente se emitir n los respectivos mensajes de error CASO DE USO Especificaci n de Proyectos DESCRIPCI N Se podr n registrar y consultar aspectos m s espec ficos del proyecto y que no se han incluido en la especificaci n anterior 3 2 1 1 RESTRICCIONES e No se pueden registrar o actualizar los aspectos espec ficos de u
103. i n m vil Dispositivos 106 8 4 1 2 3 Menu Proyectos A trav s de ste menu se pueden registrar los atributos y requerimientos de un proyecto determinado v Atributos del Proyecto En esta opci n se pueden crear modificar o eliminar atributos de un proyecto software a partir de los tipos de atributos definidos en el men Administraci n Atributos del Proyecto Crear Datos Generales Tipo Atributo Atributo Definiciones Acronimos y Abreviaturas X Guardar ae Definiciones Descripci n Acronimos EDOSA Hace referencia a la bla empresa Empaques del Oriente 5 4 Descripci n Cerrar v Requerimientos del Proyecto En esta opci n se pueden crear modificar o eliminar requerimientos de un proyecto software a partir de los tipos de requerimientos definidos en el men Administraci n 107 Requerimientos Crear Datos Generales Tipo Requerimiento Atributo Requerimientos de Rendimiento y N mero de usuarios simult neos y Guardar Numero terminales soportadas Descripci n A Numero de usuarios simultaneos El sistema estar en capacidad de soportd N mero de archivos y registyros para ad Tama o de tablas y archivos N mero de transaciones por unidad de Nombre Descripci n Cerrar 8 4 1 2 4 Menu Herramientas v Generar informe SRS En esta opci n se puede generar el documento de especificaci n de requerimientos de soft
104. icaci n y manejo de errores y recuperaci n d Efecto de los par metros e Relaci n de salidas a las entradas incluyendo secuencias de entrada salidas y las f rmulas de entrada y su conversi n a la salida 2 4 3 3 3 Requisitos de desarrollo Esta subdivisi n debe especificar los requerimientos est ticos y din micos que se pusieron en el software o en la interacci n humana con el software en conjunto Los requisitos est ticos pueden incluir a lo siguiente a N mero de terminales a ser soportadas b N mero de usuarios simult neos a ser soportados c Cantidad y tipo de informaci n que se manejara A veces se identifican los requisitos est ticos bajo una secci n separada titulada la Capacidad Por ejemplo los requisitos din micos pueden incluir los n meros de transacciones tareas y la cantidad de datos a ser procesados dentro de ciertos periodos de tiempo para condiciones de trabajo normales y m ximas Todos que estos requisitos deben declararse en condiciones mensurables Por ejemplo 95 de las transacciones se procesar n en menos de 1 seg 2 4 3 3 4 Requisitos l gicos de la base de datos Esto debe especificar los requisitos l gicos para cualquier informaci n que ser puesta en la base de datos Esto puede incluir a lo siguiente a Tipos de informaci n usadas por varias funciones b Frecuencia de uso Capacidades de acceso d Entidades de datos y sus relaciones e Restricciones de integridad
105. ification then it is not correct see 4 3 1 4 3 4 1 Internal consistency An SRS is internally consistent if and only if no subset of individual requirements described in it conflict The three types of likely conflicts in an SRS are as follows a The specified characteristics of real world objects may conflict For example 1 The format of an output report may be described in one requirement as tabular but in another as textual 2 One requirement may state that all lights shall be green while another may state that all lights shall be blue b There may be logical or temporal conflict between two specified actions For example 1 One requirement may specify that the program will add two inputs and another may specify that the program will multiply them 2 One requirement may state that A must always follow while another may require that A and occur simultaneously c Two or more requirements may describe the same real world object but use different terms for that object For example a program s request for a user input may be called a prompt in one require ment and a cue in another The use of standard terminology and definitions promotes consistency 4 3 5 Ranked for importance and or stability An SRS is ranked for importance and or stability if each requirement in it has an identifier to indicate either the importance or stability of that particular requirement Typically all of the re
106. igir una secuencia de entradas para efectuar el resultado deseado Por ejemplo en un sistema del tel fono los rasgos incluyen la llamada local llamada remitida y llamada en conferencia Cada rasgo generalmente se describe en una secuencia de estimulo respuesta e Est mulo Algunos sistemas pueden organizarse mejor describiendo sus funciones en relaci n a los est mulos Por ejemplo pueden organizarse las funciones del sistema de aterrizaje de un avi n autom tico en secciones para la p rdida del control esquivaci n del viento el cambio s bito en el destino la velocidad vertical excesiva etc f Contestaci n Algunos sistemas pueden organizarse mejor describiendo todas las funciones en apoyo a la generaci n de respuestas Por ejemplo pueden organizarse las funciones de un sistema de personal en secciones que corresponden a todas las funciones asociadas con los sueldos generados con generar una lista actual de empleados etc g Jerarqu a Funcional Cuando ninguno de los esquemas org nicos anteriores demuestra ser til la funcionalidad global puede organizarse en una jerarqu a de funciones organizada por cualesquier entradas comunes salidas comunes o el acceso com n de los datos internos Los diagramas de flujo y diccionarios de datos pueden usarse para mostrar las relaciones entre las funciones y datos 2 4 3 4 Informaci n de apoyo La informaci n de apoyo hace m s f cil el uso de la SRS Incluye lo siguiente 2 4
107. ion by feature the outline in A 5 should be used 5 3 7 5 Stimulus Some systems can be best organized by describing their functions in terms of stimuli For example the func tions of an automatic aircraft landing system may be organized into sections for loss of power wind shear sudden change in roll vertical velocity excessive etc When organizing this section by stimulus the outline in A 6 should be used 5 3 7 6 Response Some systems can be best organized by describing all the functions in support of the generation of a response For example the functions of a personnel system may be organized into sections corresponding to all functions associated with generating paychecks all functions associated with generating a current list of employees etc The outline in A 6 with all occurrences of stimulus replaced with response should be used 5 3 7 7 Functional hierarchy When none of the above organizational schemes prove helpful the overall functionality can be organized into a hierarchy of functions organized by either common inputs common outputs or common internal data access Data flow diagrams and data dictionaries can be used to show the relationships between and among the functions and data When organizing this section by functional hierarchy the outline in A 7 should be used 5 3 8 Additional comments Whenever a new SRS is contemplated more than one of the organizational techniques given in 5 3 7 7 may be appropriate
108. ios durante el desarrollo Un prototipo deber a usarse como una forma de definir los requisitos del software Pueden extraerse algunas caracter sticas como pantalla o formatos de reporte directamente del prototipo Otros requisitos pueden ser inferidos ejecutando experimentos con el prototipo 2 4 2 7 Generando el dise o en la SRS Un requisito especifica cualquier funci n externa visible o atributo de un sistema Un dise o describe un subcomponente particular de un sistema y o sus interfaces con otros subcomponentes El dise ador de la SRS debe distinguir claramente entre identificar las restricciones del dise o requeridos y proyectar un dise o espec fico Cada requisito en la SRS limita las alternativas del dise o Esto no significa sin embargo que cada requisito es el dise o La SRS debe especificar qu funciones ser n realizadas con qu datos para producir qu resultados en qu situaci n y para quien La SRS se debe enfocar en los servicios que ser n realizados 2 4 2 8 Generando los requisitos del proyecto en la SRS La SRS debe dirigir el producto software no el proceso de producir el producto software Los requisitos del proyecto representan un acuerdo entre el cliente y el proveedor de tipo contractual que pertenecen a la producci n de software y no deben ser incluidos en el SRS stos requisitos normalmente incluyen puntos como e Costo e Tiempos de la entrega e Reporte de procedimientos 18 e M to
109. is section by mode the outline in A 1 or A 2 should be used The choice depends on whether interfaces and performance are dependent on mode 18 Copyright 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 5 3 7 2 User class Some systems provide different sets of functions to different classes of users For example an elevator control system presents different capabilities to passengers maintenance workers and fire fighters When organizing this section by user class the outline in A 3 should be used 5 3 7 3 Objects Objects are real world entities that have a counterpart within the system For example in a patient monitor ing system objects include patients sensors nurses rooms physicians medicines etc Associated with each object is a set of attributes of that object and functions performed by that object These functions are also called services methods or processes When organizing this section by object the outline in A 4 should be used Note that sets of objects may share attributes and services These are grouped together as classes 5 3 7 4 Feature A feature is an externally desired service by the system that may require a sequence of inputs to effect the desired result For example in a telephone system features include local call call forwarding and confer ence call Each feature is generally described in a sequence of stimulus response pairs When organizing this sect
110. isfacci n a ste En el mbito econ mico se pretende Reducir los costos que se acrecientan cuando se presentan nuevos requerimientos a medio camino o modificaci n de los que ya existen pues debido a la documentaci n deficiente de requisitos que se maneja en algunos proyectos software estos cambios se vuelven tediosos y surgen retrasos en el cronograma y consecuentemente se incrementan los costos 2 MARCO TEORICO En el marco de ste cap tulo encontramos una introducci n a la ingenier a del software seguida por una descripci n del proceso de la ingenier a de requisitos algunas t cnicas utilizadas en la ingenier a de requisitos y termina con la descripci n del est ndar IEEE 830 utilizado en el proyecto como gu a para la especificaci n de requisitos de software 2 1 INGENIER A DEL SOFTWARE La ingenier a del software implica el estudio y la aplicaci n de un enfoque sistem tico disciplinado y cuantificable hacia el desarrollo operaci n y mantenimiento del software Dentro de las muchas definiciones que podremos encontrar acerca de la ingenier a del software R Pressman cita sta que est dada por el IEEE Est ndar IEEE 610 12 de Ingenier a del Software Se percibe la obtenci n de un objetivo espec fico y claro desarrollar soluciones software eficientes Pressman nos plantea la ingenier a del software como una tecnolog a multicapa que comprende un proceso m todos t cnicos y de gesti n y
111. ispositivo m vil basado en la plataforma Windows CE o Windows Mobile llamado Microsoft Device Emulator v1 0 3 2 HERRAMIENTAS DE DESARROLLO 3 2 1 Aplicaci n M vil Algunas de las herramientas disponibles para el desarrollo de aplicaciones en Pocket PC son J2ME java Waba y SuperWaba compatibles con java AppForge Visual Basic y Satellite Forms Visual Basic Script Para la selecci n de la herramienta de desarrollo de la aplicaci n m vil se tuvo en cuenta que la herramienta fuera de f cil aprendizaje en poco tiempo que guardara cierta familiaridad con los lenguajes utilizados y que tuviera una interfaz gr fica que facilitara el dise o Se eligi trabajar con Satellite Forms que es una herramienta de desarrollo que permite crear aplicaciones para 28 dispositivos Pocket 2002 2003 Palm OS utilizando lenguaje script para Visual Basic que result6 bastante familiar 3 2 2 Aplicaci n de Escritorio En cuanto a la herramienta seleccionada para el desarrollo de la aplicaci n de escritorio se eligi Visual Basic 6 0 de Microsoft que facilita el desarrollo de aplicaciones con interfaces gr ficas agradables al usuario a trav s de las referencias y controles que provee Adem s facilita la conexi n a bases de datos como MySQL que fue utilizado como el manejador de base de datos para la aplicaci n de escritorio 29 4 DISE O E IMPLEMENTACION DEL PROTOTIPO 4 1 METODOLOG A APLICADA Para seleccionar la m
112. iv Syed Ali Theodore K Atchinson Mikhail Auguston Robert E Barry Leo Beltracchi H Ronald Berlack Richard E Biehl Michael A Blackledge Sandro Bologna Juris Borzovs Kathleen L Briggs M Scott Buck Michael Caldwell James E Cardow Enrico A Carrara Lawrence Catchpole Keith Chan Antonio M Cicu Theo Clarke Sylvain Clermont Rosemary Coleman Virgil Lee Cooper W W Geoff Cozens Paul R Croll Gregory T Daich Geoffrey Darnton Taz Daughtrey Bostjan K Derganc Perry R DeWeese James Do Evelyn S Dow Carl Einar Dragstedt Sherman Eagles Christof Ebert Leo Egan Richard E Fairley John W Fendrich Jay Forster Kirby Fortenberry Eva Freund Richard C Fries Roger U Fujii Adel N Ghannam Marilyn Ginsberg Finner John Garth Glynn Julio Gonzalez Sanz L M Gunther David A Gustafson Jon D Hagar John Harauz Robert T Harley Herbert Hecht William Hefley Manfred Hein Mark Heinrich Mark Henley Debra Herrmann John W Horch Jerry Huller Peter L Hung George Jackelen Frank V Jorgensen William S Junk George X Kambic Richard Ron S Kenett Judith S Kerner Robert J Kierzyk Dwayne L Knirk Shaye Koenig Thomas M Kurihara John B Lane J Dennis Lawrence Fang Ching Lim William M Lively James J Longbucco Dieter Look John Lord Stan Magee David Maibor Harold Mains Robert A Martin Tomoo Matsubara Mike McAndrew Patrick D McCray Christopher McMacken Jerome W Mersky Bret Mich
113. ivo m vil Pocket PC y la aplicaci n de escritorio Para esto se debe tener activa la aplicaci n ActiveSync y seleccionar la opci n sincronizar dispositivos del men Windows Mobile 109 8 4 1 2 6 Menu Ayuda En ste men se encuentran los manuales de usuario para la aplicaci n de escritorio y m vil adem s de la ventana Acerca de con informaci n b sica de la aplicaci n 110 8 4 2 Manual de Usuario Aplicaci n M vil 8 4 2 1 Inicio de la Aplicaci n Cuando se inicia la aplicaci n m vil de PASCAR aparece la ventana de autenticaci n de usuarios donde se debe ingresar la contrase a password del usuario asignado al dispositivo Se validar que la contrase a para el acceso a la aplicaci n a G PASCAR v1 0 49 Yy lt 11 58 EY PASCAR v1 0 Windows Mobile Usuario Administrador Password Adriana Roc o P rez Rojas UIS 2006 8 4 2 2 Interfaz Principal La interfaz principal muestra el listado de los proyectos de software a cargo del usuario de la aplicaci n m vil y tiene la opci n de B squeda por proyectos El usuario debe seleccionar el proyecto del cual desea obtener informaci n 111 En esta interfaz encontramos las siguientes opciones cada proyecto PASCAR v1 0 4 Yy 4E 12 09 Proyectos Proyecto Buscar PROYECTO EL Aplicacion I Rupertino Garay Rupertino Garay Ej v Opci n Ver Permite ver los datos b si
114. ization i Window formats organization j Data formats k Command formats 1 End messages 5 3 2 Functions Functional requirements should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs These are generally listed as shall statements starting with The system shall These include a Validity checks on the inputs b Exact sequence of operations c Responses to abnormal situations including 1 Overflow 2 Communication facilities 3 Error handling and recovery d Effect of parameters e Relationship of outputs to inputs including 1 Input output sequences 2 Formulas for input to output conversion It may be appropriate to partition the functional requirements into subfunctions or subprocesses This does not imply that the software design will also be partitioned that way 5 3 3 Performance requirements This subsection should specify both the static and the dynamic numerical requirements placed on the soft ware or on human interaction with the software as a whole Static numerical requirements may include the following a The number of terminals to be supported b The number of simultaneous users to be supported c Amount and type of information to be handled 16 Copyright 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 Static numerical requirements ar
115. kes it easier to transfer the software product to new users or new machines Customers thus find it easier to transfer the software to other parts of their organization and suppliers find it easier to transfer it to new customers Serve as a basis for enhancement Because the SRS discusses the product but not the project that developed it the SRS serves as a basis for later enhancement of the finished product The SRS may need to be altered but it does provide a foundation for continued production evaluation The readers of this document are referred to Annex B for guidelines for using this recommended practice to meet the requirements of IEEE EJA 12207 1 1997 IEEE EIA Guide Industry Implementation of ISO IEC 12207 1995 Standard for Information Technology Software life cycle processes Life cycle data Copyright 1998 IEEE All rights reserved ili Participants This recommended practice was prepared by the Life Cycle Data Harmonization Working Group of the Soft ware Engineering Standards Committee of the IEEE Computer Society At the time this recommended prac tice was approved the working group consisted of the following members Edward Byrne Paul R Croll Perry DeWeese Robin Fralick Marilyn Ginsberg Finner John Harauz Mark Henley Leonard L Tripp Chair Dennis Lawrence David Maibor Ray Milovanovic James Moore Timothy Niesen Dennis Rilling The following persons were on the balloting committee
116. lo largo de las distintas fases del desarrollo DOORS de Telelogic que utiliza un tratamiento integrado de la trazabilidad de los requisitos es decir se basa en las relaciones existentes entre requisitos por motivos de jerarqu a o particionado y permite hacer an lisis de impacto top down de especificaci n a implementaci n y down top de implementaci n a especificaci n RUP Racional Unified Process de Rational Software Corporation es una metodolog a para el desarrollo de proyectos software que incluye un buen soporte para la administraci n de requerimientos y para las dem s fases del ciclo de vida del software entre otras encontramos XTie RT RequisitePro como soluciones aportan mejoras a la fase de an lisis y especificaci n de requerimientos de software En este sentido surge la idea de elaborar un prototipo software enfocado en la organizaci n y administraci n de los requisitos de software que sirva de herramienta al analista de sistemas para la captura y documentaci n de requerimientos y que preste soporte a las siguientes fases del ciclo de vida del software en la elaboraci n de productos software con mayor aceptaci n 1 2 OBJETIVOS 1 2 1 Objetivo General Dise ar e implementar un prototipo software para la captura especificaci n y documentaci n de requerimientos de software utilizando el Est ndar EEE 830 1 2 2 Objetivos Espec ficos Dise ar e implementar un prototipo software
117. ltados esperados por las partes involucradas Se puede poner las tecnolog as de la informaci n al servicio de las tecnolog as mismas donde el desarrollo de soluciones inform ticas se sirve de recursos tecnol gicos para su propio beneficio 45 6 RECOMENDACIONES El trabajo realizado en este proyecto de grado es susceptible de mejoras y por lo tanto se presentan algunas recomendaciones para trabajos futuros en sta rea de la ingenier a del software Desarrollar una herramienta para la administraci n de requerimientos de software que proporcione adem s de la definici n textual de requerimientos la definici n gr fica utilizando casos de uso Facilitar la incorporaci n y adaptaci n con otras herramientas utilizadas en el proceso de desarrollo de software para lograr un trabajo conjunto y productivo Implementar soluciones utilizando est ndares o metodolog as propuestas en el rea de la Ingenier a del Software o realizar adaptaciones que ayuden a mejorar los procesos en las fases tempranas del desarrollo del software No est de m s incursionar creativamente con nuevas metodolog as que aporten efectivamente al proceso de desarrollo de software en cualquiera de sus etapas 46 7 REFERENCIAS BIBLIOGR FICAS m PRESSMAN Roger Ingenier a del Software Un enfoque pr ctico Cuarta Edici n McGraw Hill Espa a 1998 Quinta Edici n 2002 SOMMERVILLE lan Ingenier a del Software Sexta Edici n Pe
118. mmittees of the IEEE Standards Association IEEE SA Standards Board Members of the committees serve voluntarily and without compensation They are not necessarily members of the Institute The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an inter est in participating in the development of the standard Use of an IEEE Standard is wholly voluntary The existence of an IEEE Standard does not imply that there are no other ways to produce test measure purchase market or provide other goods and services related to the scope of the IEEE Standard Furthermore the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard Every IEEE Standard is sub jected to review at least every five years for revision or reaffirmation When a document is more than five years old and has not been reaffirmed it is reasonable to conclude that its contents although still of some value do not wholly reflect the present state of the art Users are cautioned to check to determine that they have the latest edition of any IEEE Standard Comments for revision of IEEE Standards are welcome from any interested party regardless of membership affiliation with IEEE Suggestions for changes in documents should be in th
119. mplejidad etc e Portabilidad Esto debe especificar atributos de software que se relacionan con la facilidad de poner el software a otro servidor y o sistemas operativos 2 4 3 3 7 Organizar los requisitos espec ficos Por trivial que parezca el detalle de los requerimientos tiente a ser extenso Por esta raz n se recomienda ser cuidadosos al organizar stos requerimientos de una manera ptima para que sean entendibles No existe una organizaci n ptima para todos los sistemas A continuaci n se describen algunas de esas formas de organizar la SRS a Modo del sistema Algunos sistemas se comportan diferentes dependiendo del modo de operaci n Por ejemplo un sistema de control puede tener conjuntos diferentes de funciones que dependen de su modo de operaci n entrenando normal o emergencia b Clases de usuario Algunos sistemas proporcionan diferentes grupos de funciones a diferentes clases de usuarios Por ejemplo un sistema de mando de ascensor presenta las capacidades diferentes a los pasajeros obreros de mantenimiento y bomberos 25 Objetos Los objetos son entidades del mundo real que tienen una contraparte dentro del sistema Por ejemplo en un sistema que supervisa pacientes los objetos incluyen pacientes sensores enfermeras cuartos m dicos medicinas etc Asociado con cada objeto hay un grupo de atributos y funciones d Rasgo Un rasgo es un servicio deseado externamente por el sistema que puede ex
120. mpleto una caracter stica de movilidad Proyecto de Grado Modalidad Investigaci n Facultad de Ingenier as F sico Mec nicas Escuela de Ingenier a de Sistemas Director Jos C rcamo Sep lveda ABSTRACT TITLE PASCAR PROTOTYPE OF SOFTWARE APPLICATION FOR SOFTWARE REQUIREMENTS CAPTURE SPECIFICATION AND DOCUMENTATION USING IEEE 830 STANDARD AUTHOR Adriana Roc o P rez Rojas KEYWORDS Requirements Engineering IEEE 830 Standard Requirements Requirements Specification Software Engineering DESCRIPTION Software Engineering is in charge of offer methodologies and standards to improve the software development process There are software products in the market that have adapted some methodologies to take part in the software life cycle process and support the software industry but yet there are many problems related with the software solutions development because many enterprises in this software industry don t know those processes or they don t have purchasing power to purchase market solutions making their products in way inadequate PASCAR is a software prototype that uses as guide the IEEE 830 standard and it has been proposed like alternative tool to be used in the requirements engineering activities supporting requirements management inside software project This project consist of two applications a desktop prototype which support the requirements capture and management in order to generate the softwa
121. n proyecto si antes no se ha creado un proyecto para el cual definirlos CONDICIONES Los datos requeridos para realizar un registro m s detallado de un proyecto son los siguientes 35 e Prop sito e Audiencia involucrada e Alcances e Definiciones acr nimos y abreviaturas e Referencias e Resumen e Perspectivas del producto e Funciones del producto e Caracteristicas de los usuarios e Restricciones generales e Postulados y dependencias PROCESO El usuario selecciona la opci n para especificar los atributos del Proyecto El sistema despliega una interfaz para el ingreso de la informaci n requerida para la especificaci n de un proyecto existente El sistema debe validar que no se encuentren vac os los campos que se consideren obligatorios Luego de ingresar la informaci n el usuario hace clic en la opci n Guardar Si la informaci n ha sido ingresada correctamente y no se encuentran datos duplicados en el sistema se almacena la informaci n en la base de datos En caso contrario se emite el correspondiente mensaje de error ENTRADAS DEL PROCESO Todas las entradas del proceso est n dadas por las solicitadas en el formulario desplegado por el sistema SALIDAS DEL PROCESO La salida que se produce est directamente ligada con la inserci n de los datos en la tabla correspondiente en la base de datos En caso que los datos no sean ingresados correctamente se emitir n los respectivos mensajes de error
122. nas los atributos correspondientes que se crear an en esta opci n ser an Interfaces de usuario interfaces de hardware interfaces de software etc Si un tipo de requerimiento tiene registros relacionados en otras tablas no podr ser eliminado 104 Atributos de Tipos de Requerimientos Datos Generales Tipo Atributo Nombre Requerimientos Funcionales interfaces e Usuario Guardar Requerimientos Funcionales Requerimientos de Rendimiento Restricciones de Dise o Atributos Requerimientos de Interfaces Externas Requerimientos L gicos C Otros Requerimientos Descripci n as en un proyecto v Usuarios Es donde se crean modifican o eliminan los usuarios que van a utilizar la aplicaci n Crear Informaci n General C digo Nombres Apellidos 375421 23 Mar a Juliana Rojas Jaramillo Login Password Conf Password Tipo mirojasi 3 Analista de Sistemas Ingen y Guardar Analista de Sistemas Inaeniero amp Disefiador Desarrollador Administrador 137895462 Jos Vicente Jaimes Alvarado iviaimesa Cerrar 105 v Clientes En esta opci n se crean modifican o eliminan los clientes a los cuales se les va a asociar un proyecto software Clientes fro 887451233 uan Felipe Noriega Blanco i Direcci n Calle 105 52 69 San Agust n v Dispositivos Es donde se crean modifican o eliminan los dispositivos que van a ser asignados a los usuarios que van a utilizar la aplicac
123. nctional requirements 3 2 1 m Feature 1 m 3 2 1 m 1 Introduction Purpose of feature 3 2 1 m 2 Stimulus Response sequence 3 2 1 m 3 Associated functional requirements 3 2 2 User class 2 3 2 n User class n Performance requirements Design constraints Software system attributes Other requirements Copyright 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 Annex B informative Guidelines for compliance with IEEE EIA 12207 1 1997 B 1 Overview The Software Engineering Standards Committee SESC of the IEEE Computer Society has endorsed the policy of adopting international standards In 1995 the international standard ISO IEC 12207 Information technology Software life cycle processes was completed The standard establishes a common framework for software life cycle processes with well defined terminology that can be referenced by the software industry In 1995 the SESC evaluated ISO IEC 12207 and decided that the standard should be adopted and serve as the basis for life cycle processes within the IEEE Software Engineering Collection The IEEE adaptation of ISO IEC 12207 is IEEE EIA 12207 0 1996 It contains ISO IEC 12207 and the following additions improved compliance approach life cycle process objectives life cycle data objectives and errata The implementation of ISO IEC 12207 within the IEEE also includes the following 12207 1 1997 IEEE EIA Guide for
124. nguages One way to avoid the ambiguity inherent in natural language is to write the SRS in a particular requirements specification language Its language processors automatically detect many lexical syntactic and semantic errors One disadvantage in the use of such languages is the length of time required to learn them Also many non technical users find them unintelligible Moreover these languages tend to be better at expressing certain types of requirements and addressing certain types of systems Thus they may influence the requirements in subtle ways 4 3 2 3 Representation tools In general requirements methods and languages and the tools that support them fall into three general cate gories object process and behavioral Object oriented approaches organize the requirements in terms of real world objects their attributes and the services performed by those objects Process based approaches organize the requirements into hierarchies of functions that communicate via data flows Behavioral approaches describe external behavior of the system in terms of some abstract notion such as predicate calculus mathematical functions or state machines The degree to which such tools and methods may be useful in preparing an SRS depends upon the size and complexity of the program No attempt is made here to describe or endorse any particular tool When using any of these approaches it is best to retain the natural language descriptions T
125. olog as para el desarrollo del software que se encuentran definidas para soportar las actividades propias del ciclo de vida del software Algunas de ellas son 1 Modelo Lineal Secuencial Cascada Pura Es la base para otros modelos m s efectivos de ciclo de vida Un proyecto software basado en esta metodolog a progresa a trav s de una secuencia ordenada de pasos que no permite el avance a la siguiente actividad hasta tanto no se haya revisado y terminado la actual El modelo define las siguientes actividades para el ciclo de vida an lisis de requerimientos dise o codificaci n y pruebas ste modelo ha sido transformado en la metodolog a de cascadas modificadas a trav s del solapamiento de las fases descritas para permitir un mayor avance a trav s del proyecto El modelo lineal secuencial tambi n se ha utilizado en el modelo DRA Desarrollo R pido de Aplicaciones utilizando una construcci n basada en componentes y permitiendo desarrollos en periodos cortos de tiempo 2 Modelo de Construcci n de Prototipos Este modelo se centra en el desarrollo de los aspectos m s visibles del software a trav s de un dise o r pido que da entrada a la definici n de requerimientos m s espec ficos a medida que avanza el proyecto Se basa en el desarrollo de prototipos de software que utilizan la realimentaci n proporcionada por el cliente hasta el desarrollo del producto final Las tareas propuestas para este modelo son an lisis de r
126. or SRD in IEEE EJA 12207 1 1997 are prescribed by 6 22 of IEEE EIA 12207 1 1997 A compliant SRD shall achieve the purpose stated in 6 22 1 of IEEE EIA 12207 1 1997 The purpose of the SRD is TEEE EIA 12207 1 1997 subclause 6 22 1 Purpose Specify the requirements for a soft ware item and the methods to be used to ensure that each requirement has been met Used as the basis for design and qualification testing of a software item An SRS complying with this recommended practice and meeting the additional requirements of Table B 3 of this recommended practice would achieve the stated purpose An SRD compliant with IEEE EIA 12207 1 1997 shall satisfy the specific content requirements provided in 6 22 3 and 6 22 4 of that standard Table B 3 of this recommended practice lists the specific content items and where appropriate references the clause of this recommended practice that requires the same informa tion An SRD specified according the requirements stated or referenced in Table B 3 of this recommended prac tice shall be evaluated considering the criteria provided in 5 3 4 2 of IEEE EIA 12207 0 1996 Table B 3 Coverage of specific SRD requirements by IEEE Std 830 1998 TEEE EIA 12207 1 1997 Corresponding clauses of Additions to requirements of specific content IEEE Std 830 1998 IEEE Std 830 1998 a Generic description information See Table B 2 b System identification and 5 1 1 Scope overview c Functionality of the
127. otyping is used frequently during the requirements portion of a project Many tools exist that allow a prototype exhibiting some characteristics of a system to be created very quickly and easily See also ASTM E1340 96 Prototypes are useful for the following reasons a The customer may be more likely to view the prototype and react to it than to read the SRS and react to it Thus the prototype provides quick feedback b The prototype displays unanticipated aspects of the systems behavior Thus it produces not only answers but also new questions This helps reach closure on the SRS c An SRS based on a prototype tends to undergo less change during development thus shortening development time A prototype should be used as a way to elicit software requirements Some characteristics such as screen or report formats can be extracted directly from the prototype Other requirements can be inferred by running experiments with the prototype 4 7 Embedding design in the SRS A requirement specifies an externally visible function or attribute of a system A design describes a particu lar subcomponent of a system and or its interfaces with other subcomponents The SRS writer s should clearly distinguish between identifying required design constraints and projecting a specific design Note that every requirement in the SRS limits design alternatives This does not mean though that every require ment is design Copyright 1998 IEEE All ri
128. pci n del proyecto en funci n del Descrip FONGENAR atributo seleccionado Fecha Mod VARCHAR 10 Fecha de modificaci n del atributo del proyecto Mod VARCHAR 10 Hora de modificaci n del atributo del proyecto Usu Mod VARCHAR 10 Usuario que modific el atributo del proyecto Tabla 20 Tabla Atributos de Proyectos Aplicaci n movil Pascar Nombre Tabla M_PROYECTOS Descripci n Almacena los datos identificadores de cada proyecto M_PROYECTOS CAMPO TIPO LONG DESCRIPCI N C digo nico alfa num rico que representa Prey VARCHAR 6 la identificaci n de un proyecto Nombre VARCHAR 100 Nombre del proyecto Id Cliente VARCHAR 10 Identifica el cliente del proyecto software Nombre Cli VARCHAR 100 Nombre del cliente del proyecto Tabla 21 Tabla Proyectos Aplicaci n m vil Pascar 92 Nombre Tabla M_TIPOS REQ Descripci n Almacena los tipos de requerimientos que se utilizan para detallar un proyecto M_TIPOS_REQ CAMPO TIPO LONG DESCRIPCI N Cod_Tipo VARCHAR 10 Identifica de requerimiento Nombre VARCHAR 50 Nombre del tipo de requerimiento Tabla 22 Tabla Tipos de Requerimientos Aplicaci n m vil Pascar Nombre Tabla M_ATRIBUTOS_TIPOS_RE M_ATRIBUTOS_TIPOS_REQ Descripci n Almacena los atributos correspondientes a un tipo de requerimientos M_ATRIBUTOS_TIPOS_RE CAMPO TIPO LONG DESCRIPCI N Cod Atrib VARCHA
129. por los usuarios operadores u otros sistemas externos Estos requisitos deben incluir por lo menos una descripci n de cada entrada est mulo en el sistema cada salida respuesta del sistema y todas las funciones realizadas por el sistema en respuesta a una salida o a una entrada o que apoye una salida Esta es la parte m s grande y m s importante del SRS 2 4 3 3 1 Interfaces externas sta debe ser una descripci n detallada de todas las entradas y salidas del sistema software Debe complementar las descripciones de interfaces descritas y no debe repetirse la informaci n all Debe estructurarse como sigue a Nombre de item b Descripci n de prop sito Fuente de entrada o destino de salida d Rango v lido exactitud y o tolerancia e Unidades de medida f Tiempos g Relaciones a otras entradas salidas h Formato de pantalla organizaci n i Formato de ventanas organizaci n j Formatos de los datos k Formatos de los comandos 23 2 4 3 3 2 Funciones Los requisitos funcionales deben definir las acciones fundamentales que deben tener lugar en el software en la aceptaci n y procesamiento de las entradas y las salidas stos generalmente se listan como declaraciones debe que empiezan con El sistema debe stos incluyen a Verificar la validez sobre las entradas b Secuencia exacta de las operaciones Respuestas a situaciones anormales incluyendo desbordamiento facilidades de comun
130. quire ment in the SRS having a unique name or reference number The forward traceability of the SRS is especially important when the software product enters the operation and maintenance phase As code and design documents are modified it is essential to be able to ascertain the complete set of requirements that may be affected by those modifications 4 4 Joint preparation of the SRS The software development process should begin with supplier and customer agreement on what the completed software must do This agreement in the form of an SRS should be jointly prepared This is important because usually neither the customer nor the supplier is qualified to write a good SRS alone a Customers usually do not understand the software design and development process well enough to write a usable SRS b Suppliers usually do not understand the customer s problem and field of endeavor well enough to specify requirements for a satisfactory system Therefore the customer and the supplier should work together to produce a well written and completely understood SRS A special situation exists when a system and its software are both being defined concurrently Then the func tionality interfaces performance and other attributes and constraints of the software are not predefined but rather are jointly defined and subject to negotiation and change This makes it more difficult but no less important to meet the characteristics stated in 4 3 In par
131. quirements that relate to a software product are not equally important Some require ments may be essential especially for life critical applications while others may be desirable 6 Copyright 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 Each requirement in the SRS should be identified to make these differences clear and explicit Identifying the requirements in the following manner helps a Have customers give more careful consideration to each requirement which often clarifies any hidden assumptions they may have b Have developers make correct design decisions and devote appropriate levels of effort to the differ ent parts of the software product 4 3 5 1 Degree of stability One method of identifying requirements uses the dimension of stability Stability can be expressed in terms of the number of expected changes to any requirement based on experience or knowledge of forthcoming events that affect the organization functions and people supported by the software system 4 3 5 2 Degree of necessity Another way to rank requirements is to distinguish classes of requirements as essential conditional and optional a Essential Implies that the software will not be acceptable unless these requirements are provided in an agreed manner b Conditional Implies that these are requirements that would enhance the software product but would not make it unacceptable if they are absent
132. r a de Requisitos Ingenier a de Requerimientos 4 Frederick P Brooks Jr The Mythical Man Month Addison Wesley 1995 5 Citado en PRESSMAN Roger Ingenier a del Software un enfoque pr ctico Quinta Edici n McGraw Hill Espa a 2002 Cap tulo 10 P g 171 175 y Cap tulo 11 P g 181 2 2 1 Identificaci n de Requisitos El prop sito de sta actividad es comprender las verdaderas necesidades del negocio a trav s de una buena comunicaci n entre el equipo desarrollador del proyecto software y el cliente Luego los objetivos trazados van desde la comprensi n del rea del negocio del cliente la evaluaci n de las necesidades planteadas hasta la propuesta de una soluci n favorable y de calidad para resolver el problema Es sta fase del an lisis del problema se deben tener en cuenta ciertos aspectos que ayuden a garantizar un acuerdo entre las partes involucradas en el proyecto e Identificar qui nes son realmente los involucrados y afectados con el desarrollo del producto software de manera directa e indirecta es decir determinar qui n es el usuario que usara el sistema desarrollado qui n se encargar de su desarrollo soporte y mantenimiento qui n se ver beneficiado con la elaboraci n del proyecto software e Entender el problema y vislumbrar desde los diferentes puntos de vista de los involucrados la soluci n m s factible tomando en cuenta tanto la perspectiva de cliente como la perspectiva t cnica del
133. r el sistema el usuario guarda la informaci n e Los datos son insertados o actualizados en las tablas correspondiente en la base de datos e ENTRADAS DEL PROCESO El usuario ingresa los campos correspondientes dentro de un formulario para definir un nuevo tipo de requerimiento junto con sus atributos o para modificarlos 43 e SALIDAS DEL PROCESO Los datos son insertados en las tablas correspondientes en la base de datos son actualizados si el tipo de requerimiento ya estaba definido previamente Si los datos son ingresados de manera err nea se deben emitir los correspondientes mensajes de error 4 4 6 3 CASO DE USO Registrar Dispositivos e DESCRIPCI N Permite registrar modificar o eliminar los dispositivos que han de ser sincronizados con la aplicaci n de escritorio e RESTRICCIONES El usuario autorizado para realizar las tareas de registro y actualizaci n mencionadas es el administrador del sistema e PROCESO El usuario selecciona la opci n Dispositivos El usuario ingresa los datos correspondientes para registrar un nuevo dispositivo o para actualizar Luego de validados los datos por el sistema el usuario guarda la informaci n Los datos son insertados o actualizados en las tablas correspondiente en la base de datos e ENTRADAS DEL PROCESO El usuario ingresa los campos correspondientes dentro de un formulario para definir un nuevo dispositivo o para modificarlo e SALIDAS DE
134. re requirements specification SRS document and a mobile prototype which is used like auxiliary tool to capture and management the software requirements in a mobile device Pocket PC from place where it be necessary the first one is independent of the second one but the second prototype is added to project like aggregate value to give a mobility characteristic to complete prototype Degree Project Faculty of Physical Mechanical Engineering Systems Engineering School Director Jos Carcamo Sep lveda TABLA DE CONTENIDO INTRODUCCION o ol 1 1 PLANTEAMIENTO DEL PROBLEMA cccccceeeeeeeeeeeseeeeeeeeneananes 2 1 1 DEFINICI N DEL PROBLEMA o n 2 1 2 OBJETIVOS A AA A A aunt kad 4 1 2 1 Objetivo General usd a ida 4 1 2 2 Objetivos ESPECIES ts aaa 4 1 3 ALCANCES a A A 5 1 4 IMPACT O AAA AA A 5 2 MARCO TEORICO dio 7 2 1 INGENIER A DEL SOFTIWARE list cies cansino ae deere sone oe 7 2 2 INGENIER A DE REQUISITOS IR eeren 9 2 2 1 Identificaci n de 0 10 2 2 2 An lisis y Negociaci n de 10 2 2 3 Especificaci n de Requisitos SRS 11 2 2 4 Modelado del Sistemasi 12 2 2 5 Validaci n y Gesti n de Requisitos
135. rfaz principal 113
136. ributo tiene registros relacionados en otras tablas no podr ser eliminado Atributos de Proyectos Datos Generales Tipo Atributo Nombre Alcance y Metas Guardar A Funciones del producto Caracter sticas de Usuario Referencias Resumen Perspectivas del Producto Definiciones Acr nimos y Abreviatur Introducci n Descripci n Alcance v Tipos de Requerimientos En esta opci n se pueden crear modificar o eliminar tipos de requerimientos de un proyecto Estos tipos de requerimientos corresponden a clasificaciones generales utilizadas para la especificaci n de requerimientos de un proyecto por ejemplo requerimientos funcionales de rendimiento de dise o entre otros Si un tipo de requerimiento tiene registros relacionados en otras tablas no podr ser eliminado 103 Tipos de Requerimientos r Datos Generales C digo Nombre Requerimietnos L gicos Descripci n Se definen los requerimientos l gicos utilizados en el proyecto Descripci n Requerimietnos L gicos Se definen los requerimientos l gicos utilizados en el pre PASCAR 1 El tipo de requerimiento se ha creado satisfactoriamente Cerrar v Atributos de Tipos de Requerimientos En esta opci n se pueden crear modificar o eliminar atributos que pertenezcan a los tipos de requerimientos definidos en la opci n anterior Por ejemplo si se cre un tipo de requerimiento llamado Requerimientos de Interfaces Exter
137. ridad experiencia y formaci n t cnica 2 4 3 2 4 Restricciones Esta subdivisi n de la SRS debe proporcionar una descripci n general de cualquier otro punto que limitar las opciones de los dise adores Esto incluye a pol ticas reguladoras b limitaciones de Hardware Interfaces con otras aplicaciones d Operaciones en Paralelo e Funciones de Auditoria f Funciones de Control g Requisitos de lenguaje 22 h Protocolos i Requisitos de Fiabilidad j Seguridad y consideraciones de garantia 2 4 3 2 5 Suposiciones y dependencias Esta subdivisi n de la SRS debe listar cada uno de los factores que afectan los requisitos declarados en la SRS Estos factores no son restricciones de dise o del software pero son m s bien cualquier cambio que puede afectar los requisitos en la SRS Por ejemplo una suposici n puede ser que un sistema operativo espec fico estar disponible para el hardware designado para el producto software Si de hecho el sistema operativo no est disponible la SRS tendr a que cambiar de acuerdo a ste suceso 2 4 3 3 Requisitos espec ficos Esta secci n de la SRS debe contener todos los requisitos del software a un nivel de detalle suficiente para permitirles a los dise adores dise ar un sistema para satisfacer esos requisitos y a los auditores probar que el sistema satisface esos requisitos A lo largo de esta secci n cada requisito declarado debe ser externamente perceptible
138. rollo de ste proyecto 1 1 DEFINICI N DEL PROBLEMA En el rea de la Ingenier a del Software se define el Ciclo de Vida del software como el conjunto de procesos y t cnicas aplicadas al desarrollo de un producto software desde que se concibe la necesidad de crearlo hasta que termina su explotaci n Dentro del ciclo de vida se encuentran varios procesos b sicos entre los cuales est la Definici n de Requisitos que comprende aquellas actividades que traducen las necesidades del cliente del producto en un modelo consistente que define la estructura y el comportamiento del software a desarrollar En los ltimos a os las organizaciones han aumentado la demanda del software en su af n por actualizarse y administrar de manera eficiente y competitiva su informaci n pero muchas de ellas se han encontrado con productos software que no cumplen con sus especificaciones son incompletos y de mala calidad Esta situaci n puede ser consecuencia de un problema que se origina en las fases iniciales del ciclo de vida del software la especificaci n deficiente de requerimientos dentro de un proyecto software Para este problema podemos encontrar los siguientes s ntomas y efectos No hay una comprensi n del dominio de la aplicaci n por parte del equipo que esta involucrado en el proyecto y por tanto no se define claramente el resultado que se desea obtener del producto software e Falta establecer una separaci n entre
139. s declaraciones similares en las especificaciones de alto nivel por ejemplo las especificaciones de los requisitos del sistema si ellos existen 2 4 3 1 3 Definiciones siglas y abreviaciones Esta subdivisi n debe proporcionar las definiciones de todas las condiciones las siglas y abreviaciones requeridas para interpretar la SRS apropiadamente Esta informaci n puede proporcionarse por la referencia a uno o m s ap ndices en la SRS o por la referencia a otros documentos 2 4 3 1 4 Referencias Esta subdivisi n debe a Proporcionar una lista completa de todos los documentos referenciados en cualquier parte de la SRS b Identificar cada documento por t tulo n mero del reporte si es aplicable fecha de publicaci n y editorial c Especificar las fuentes de las referencias de donde se obtuvieron Esta informaci n puede proporcionarse por la referencia a un ap ndice o a otro documento 2 4 3 1 5 Apreciaci n global Esta subdivisi n debe a Describir lo que contiene el resto de la SRS b Explicar c mo est organizada la SRS 2 4 3 2 Descripci n global Esta secci n de la SRS debe describir los factores generales que afectan el producto y sus requisitos Esta secci n no declara los requisitos espec ficos En cambio provee un fondo para esos requisitos que se definen en detalle en la Secci n 3 de la SRS y los hacen m s f cil entender Esta secci n normalmente consiste en seis subdivisiones como sigue 2
140. s del o PASCAR jl El proyecto se ha creado satisfactoriamente Cerrar En el tab Modificar se encuentran las opciones para modificar los datos ingresados al proyecto creado que pertenezcan al usuario que est utilizando la aplicaci n v Abrir Proyecto En esta opci n el usuario podr buscar los proyectos que est n a su cargo ingresando como par metro de b squeda alguna palabra que pertenezca al nombre del proyecto que necesita abrir Si el usuario no est seguro sobre qu palabra ingresar puede dejar esta casilla en blanco y seleccionar la opci n Buscar que listar todos los proyectos de ese usuario en ese momento 100 Abrir Proyecto Buscar Nombre del proyecto p Empiece Contenga Buscar Proyecto 1 2006 04 09 Juan Bedoya Personal Proyecto 2 2006 04 09 Lorenzo Casta o Empaques del orier Sistema para el manejo de person 2006 05 13 Lorenzo Castafio Empaques del orier Abrir Cerrar Luego el usuario seleccionar el proyecto y la opci n Abrir para cargar el proyecto al sistema y habilitar las opciones que dependan de este proceso v Cerrar Sesi n Con esta opci n se vuelve la interfaz de acceso v Salir Es la opci n para finalizar la aplicaci n 8 4 1 2 2 Men Administraci n NOTA Para una mejor compresi n de la organizaci n del proyecto se recomienda leer el est ndar IEEE 830 o en su defecto el apartado del cap tulo 2 dedicado a la descripci n de est ndar
141. s unambiguous if and only if every requirement stated therein has only one interpretation As a minimum this requires that each characteristic of the final product be described using a single unique term 4 Copyright 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 In cases where a term used in a particular context could have multiple meanings the term should be included in a glossary where its meaning is made more specific An SRS is an important part of the requirements process of the software life cycle and is used in design implementation project monitoring verification and validation and in training as described in IEEE Std 1074 1997 The SRS should be unambiguous both to those who create it and to those who use it However these groups often do not have the same background and therefore do not tend to describe software require ments the same way Representations that improve the requirements specification for the developer may be counterproductive in that they diminish understanding to the user and vice versa Subclauses 4 3 2 1 through 4 3 2 3 recommend how to avoid ambiguity 4 3 2 1 Natural language pitfalls Requirements are often written in natural language e g English Natural language is inherently ambigu ous A natural language SRS should be reviewed by an independent party to identify ambiguous use of language so that it can be corrected 4 3 2 2 Requirements specification la
142. se hace la recomendaci n Hora_Crea VARCHAR 10 Hora en la que se hace la recomendaci n Codigo_Usuario VARCHAR 10 Codigo que identifica al usuario que hace la recomendaci n Codigo Proyecto VARCHAR 10 Codigo del proyecto al que pertenece la recomendaci n Tabla 13 Tabla Recomendaciones Aplicaci n de escritorio Pascar Nombre Tabla Tbl_PROYECTOS_ USUARIOS Descripci n Identifica la relaci n existente entre un proyecto y sus usuarios PROYECTOS_ USUARIOS CAMPO TIPO LONG DESCRIPCI N Codigo_Relacion VARCHAR 10 C digo nico de identificaci n de la relaci n proyecto usuario Codigo Proyecto VARCHAR 10 Identifica un proyecto determinado Codigo_Usuario VARCHAR 10 Identifica a un usuario de un proyecto Tabla 14 Tabla Proyectos Usuarios Aplicaci n de escritorio Pascar Nombre Tabla AUDITORIA Descripci n Es la bit cora de la aplicaci n donde se almacenan los cambios que un usuario ha realizado dentro de de la SRS de un proyecto Tbl_ AUDITORIA CAMPO TIPO LONG DESCRIPCI N Codigo_Usuario VARCHAR 10 ae identificar el usuario que a realizado los cambios Codigo_Evento VARCHAR 10 Codigo del evento que se genera al realizar un cambio Fecha en la cual se realiza un cambio Fecha VARCHAR 10 dentro de la especificaci n de req del proyecto Hora VARCHAR 10 Hora en la cual se realiza el cambio Codigo del proyecto al cual se realiza Codigo_Pro
143. suario que haya ingresado Si el usuario no coincide con ninguno de los usuarios registrados se emitir un mensaje de error que indique el no acceso a la aplicaci n e ENTRADAS DEL PROCESO e Nombre de usuario login y Contrase a password 33 e SALIDAS DEL PROCESO e Entorno de trabajo de la aplicaci n disponible para el usuario autenticado e Mensajes de error del sistema cuando la identificaci n del usuario no sea v lida 4 4 2 Gesti n de proyectos de Software Administraci n de Proyectos Usuario Aplicaci n M vil Especificaci n de Proyectos Usuario Aplicaci n de Escritorio Figura 5 Caso de Uso Gesti n de Proyectos de Software 4 4 2 1 CASO DE USO Administraci n de Proyectos e DESCRIPCI N A trav s de ste caso de uso se podr n crear nuevos proyectos para la captura y administraci n de requerimientos de software Se registrar n los datos m s generales del proyecto y en caso que el proyecto exista se podr n modificar estos datos Esta tarea ser realizada nicamente por el analista de sistemas e RESTRICCIONES e No pueden registrarse dos proyectos con el mismo nombre y o c digo de identificaci n e CONDICIONES Los datos requeridos para realizar un registro preliminar o la modificaci n de un proyecto son los siguientes e C digo de identificaci n del proyecto e Nombre del proyecto e Fecha de creaci n del proyecto e de creaci n del proyecto e Identificac
144. ticular an SRS that does not comply with the requirements of its parent system specification is incorrect 8 Copyright 1998 IEEE All rights reserved IEEE SOFTWARE REQUIREMENTS SPECIFICATIONS Std 830 1998 This recommended practice does not specifically discuss style language usage or techniques of good writ ing It is quite important however that an SRS be well written General technical writing books can be used for guidance 4 5 SRS evolution The SRS may need to evolve as the development of the software product progresses It may be impossible to specify some details at the time the project is initiated e g it may be impossible to define all of the screen formats for an interactive program during the requirements phase Additional changes may ensue as defi ciencies shortcomings and inaccuracies are discovered in the SRS Two major considerations in this process are the following a Requirements should be specified as completely and thoroughly as is known at the time even if evolutionary revisions can be foreseen as inevitable The fact that they are incomplete should be noted b A formal change process should be initiated to identify control track and report projected changes Approved changes in requirements should be incorporated in the SRS in such a way as to 1 Provide an accurate and complete audit trail of changes 2 Permit the review of current and superseded portions of the SRS 4 6 Prototyping Prot
145. tion 3 3 supplier The person or persons who produce a product for a customer In the context of this recom mended practice the customer and the supplier may be members of the same organization 3 4 user The person or persons who operate or interact directly with the product The user s and the customer s are often not the same person s 4 Considerations for producing a good SRS This clause provides background information that should be considered when writing an SRS This includes the following a Nature of the SRS b Environment of the SRS c Characteristics of a good SRS d Joint preparation of the SRS SRS evolution f Prototyping g Embedding design in the SRS h Embedding project requirements in the SRS 4 1 Nature of the SRS The SRS is a specification for a particular software product program or set of programs that performs certain functions in a specific environment The SRS may be written by one or more representatives of the supplier one or more representatives of the customer or by both Subclause 4 4 recommends both The basic issues that the SRS writer s shall address are the following a Functionality What is the software supposed to do b External interfaces How does the software interact with people the system s hardware other hard ware and other software c Performance What is the speed availability response time recovery time of various software func tions etc
146. tocolos de redes locales etc f Restricciones de memoria Esto debe especificar cualquier caracteristica aplicable y limites en la memoria primaria y secundaria g Funcionamiento Esto debe especificar el modo de funcionamiento normal y especial requerido por el usuario como a Los varios modos de funcionamiento del usuario en la organizaci n b Los Periodos de funcionamientos activos e inactivos c Datos que procesan las funciones de apoyo d Operaciones de recuperaci n y copia de seguridad NOTA Esto a veces se especifica como parte de la secci n de interfaces de usuario h Requisitos de adaptaci n Esto debe a Definir los requisitos para cualquier dato o secuencia de inicializaci n que son espec ficos a un sitio dado misi n o modo de operaci n b Especifique el sitio o los rasgos que se deben relacionar que deben modificarse para adaptar el software a una instalaci n particular 2 4 3 2 2 Funciones del Producto Esta subdivisi n de la SRS debe proporcionar un resumen de las funciones principales que el software realizar A veces el resumen de la funci n que es necesario para esta parte puede tomarse directamente de la secci n de especificacines de alto nivel si existe eso asigna las funciones particulares al producto del software 2 4 3 2 3 Caracter sticas del usuario Esta subdivisi n de la SRS debe describir esas caracter sticas generales de los usuarios del producto que incluye nivel de escola
147. tos por el sistema el usuario guarda la informaci n e Los datos son insertados o actualizados en las tablas correspondiente en la base de datos 42 e ENTRADAS DEL PROCESO El usuario ingresa los campos correspondientes dentro de un formulario para definir un nuevo usuario para modificarlo e SALIDAS DEL PROCESO Los datos son insertados en las tablas correspondientes en la base de datos o son actualizados si el usuario ya estaba registrado previamente Si los datos son ingresados de manera err nea se deben emitir los correspondientes mensajes de error NOTA El proceso para registro modificaci n y eliminaci n de clientes mantiene una estructura similar por lo que se emite la descripci n de ste caso de uso 4 4 6 2 CASO DE USO Registrar tipos de requerimientos e DESCRIPCI N En este caso de uso se permite registrar o modificar las tablas de soporte de los diferentes tipos de requerimientos con sus atributos e RESTRICCIONES Los usuarios autorizados para realizar las tareas de registro y actualizaci n mencionadas son el administrador del sistema y el ingeniero de requisitos analista de sistemas que puede ser el mismo administrador del sistema e PROCESO e El usuario selecciona la opci n del men correspondiente requerimientos e El usuario ingresa los datos correspondientes para registrar o para actualizar un nuevo tipo de requerimiento y agrega sus atributos e Luego de validados los datos po
148. uld be careful not to go beyond the bounds of that role This means the SRS a Should correctly define all of the software requirements A software requirement may exist because of the nature of the task to be solved or because of a special characteristic of the project b Should not describe any design or implementation details These should be described in the design stage of the project c Should not impose additional constraints on the software These are properly specified in other documents such as a software quality assurance plan Therefore a properly written SRS limits the range of valid designs but does not specify any particular design 4 3 Characteristics of a good SRS An SRS should be a Correct b Unambiguous c Complete d Consistent e Ranked for importance and or stability f Verifiable g Modifiable h Traceable 4 3 1 Correct An SRS is correct if and only if every requirement stated therein is one that the software shall meet There is no tool or procedure that ensures correctness The SRS should be compared with any applicable superior specification such as a system requirements specification with other project documentation and with other applicable standards to ensure that it agrees Alternatively the customer or user can determine if the SRS correctly reflects the actual needs Traceability makes this procedure easier and less prone to error see 4 3 8 4 3 2 Unambiguous An SRS i
149. ulo utilizado para la administraci n de usuarios de la aplicaci n y la administraci n de los dispositivos m viles que tendr n acceso a la aplicaci n Adem s se podr n adicionar y administrar los tipos de requerimientos y atributos que puedan ser utilizados para la especificaci n de un proyecto 4 3 ACTORES DE LA APLICACI N e ACTORES PASCAR PARA EL PROTOTIPO DE ESCRITORIO a Actor Administrador Es el usuario con acceso a todas las funcionalidades de la aplicaci n de escritorio quien administra usuarios dispositivos y hace mantenimiento de la base de datos ste actor puede ser un analista de sistemas b Actor Analista de Sistemas Ingeniero de Requerimientos Es el usuario encargado de administrar los proyectos software a su mando Tendr a su disposici n gran parte de las funcionalidades de la aplicaci n c Actor Dise ador Desarrollador de software Es un usuario secundario de la aplicaci n que podr consultar la informaci n y documentaci n relacionada con los proyectos pero solo podr hacer sugerencias y recomendaciones acerca de los cambios que deben realizarse en la especificaci n de los requerimientos de software e ACTORES PASCAR PARA EL PROTOTIPO M VIL a Actor Analista de Sistemas Ingeniero de Requerimientos Es el nico usuario de la aplicaci n m vil Tendr a su disposici n todas las funcionalidades de la aplicaci n m vil 4 4 CASOS DE USO De acuerdo a los m dulos funcionales e
150. utos de la aplicaci n En esta parte se describen los atributos de seguridad mantenibilidad de la aplicaci n portabilidad y disponibilidad de la misma e Requerimientos l gicos Hace referencia a la especificaci n de los tipos de datos utilizados la frecuencia de uso de los datos el acceso a los mismos y la integridad que deben manejar los datos e Otros requerimientos Son los que no se encuentren dentro de la clasificaci n antes listada RESTRICCIONES Las tablas de soporte donde se definen los tipos de requerimientos y sus atributos no deben encontrarse vac as Para el caso de un requerimiento que no se encuentre dentro de la clasificaci n definida se debe ingresar por el m dulo de administraci n para requerimientos y crearlo PROCESO El usuario ingresa a un formulario que contiene cada una de las clasificaciones de tipos de requerimientos mencionadas anteriormente Cada tipo de requerimiento posee unos atributos propios que se deben registrar manualmente por parte del usuario Cuando se haya terminado la especificaci n de un requerimiento el usuario debe hacer clic en la opci n guardar para salvar el requerimiento dentro del proyecto El sistema debe validar los campos que se encuentren vac os y se consideren obligatorios Si la informaci n est completa los datos se deben almacenar en la tabla de requerimientos ENTRADAS DEL PROCESO Las entradas del proceso est n dadas por el formulario para el ingreso de
151. ware SRS del proyecto activo en formato RTF El sistema informar la ruta en donde qued guardado el documento Generar Documento de SRS El documento de SRS se ha generado en la siguiente ruta a EMADRIANAAPASCAR Desktop 4rchivos_SRS Sistema para el 7 manejo de personal de Empaques del Oriente S A rtf 108 v Recomendaciones A esta opci n pueden tener acceso los ingenieros que trabajan en un proyecto software pero que no estan encargados de la especificaci n de requerimientos del mismo A trav s de sta opci n se pueden crear nuevas recomendaciones a los requerimientos definidos dentro de un proyecto El usuario debe seleccionar el tipo de requerimiento del cual tiene inquietud e ingresar la descripci n de la sugerencia a realizar para poder guardarla Tambi n podr consultar las recomendaciones realizadas a ese proyecto con anterioridad 8 4 1 2 5 Crear Recomendaciones Buscar Requerimiento Tipo Requerimiento Atributo Requerimiento Requerimientos de Rendimiento v N mero de usuarios simult neos Nombre Descripci n REQ P 0003 00002 Se espera que el sistema soporte una buena cantidad de usuarios cone Agregar Recomendaci n Nombre Aclaraci n Requerimiento P 0003 00002 Descripci n No es claro cu l es la cantidad de usuarios que debe soportar el sistema Se solici Men Windows Mobile Desde este men se puede realizar la sincronizaci n de datos entre el disposit
152. xpuestos anteriormente y a los actores definidos se describen los casos de uso propuestos para el prototipo PASCAR 32 4 4 1 Autenticaci n de usuarios 4 4 1 1 CASO DE USO Autenticaci n de Usuarios Autenticaci n de Usuarios Usuario Aplicaci n Usuario Aplicaci n de Escritorio M vil Figura 4 Caso de Uso Autenticaci n de Usuarios e DESCRIPCI N Este caso de uso describe el acceso a la aplicaci n que pueden tener el administrador del sistema el analista de sistemas o ingeniero de requerimientos y el ingeniero de desarrollo o dise ador que se encuentren registrados y activos en el sistema El acceso en la aplicaci n m vil est restringido para uso exclusivo del analista de sistemas e RESTRICCIONES e El usuario debe estar registrado y activo en el sistema e Para el acceso a la aplicaci n m vil el usuario debe tener asignado y registrado un dispositivo m vil o PDA e PROCESO 1 El usuario Ingresa al sistema su login nombre de usuario y su password contrase a 2 El usuario hace clic en el bot n Aceptar 3 El sistema debe validar que no se encuentren vac os los campos de login y password 4 El sistema debe verificar que el login y password de usuario sean v lidos es decir que se encuentren registrados en la base de datos del sistema 5 Si el usuario se encuentra registrado en el sistema se permitir el ingreso a la aplicaci n con las funcionalidades disponibles de acuerdo al tipo de u
153. yecto VARCHAR 6 el cambio en la especificaci n de req del software Tabla 15 Tabla Auditoria Aplicaci n de escritorio Pascar 90 8 2 2 Diccionario de Datos Aplicaci n M vil Nombre Tabla M_USUARIOS e Descripci n Almacena los datos identificadores de los usuarios M_USUARIOS CAMPO TIPO LONG DESCRIPCI N Codigo_Usu VARCHAR 10 Identifica a un usuario determinado Nombre_usu VARCHAR 100 Nombre completo del usuario Password VARCHAR 10 Contrase a de autenticaci n del usuario Nombre Dis VARCHAR 50 Nombre nico del dispositivo Nota LONGCHAR Anotaci n Descripci n del dispositivo Tabla 16 Tabla Usuarios Aplicaci n m vil Pascar Nombre Tabla M_CLIENTES e Descripci n Almacena los datos identificadores de los clientes M_CLIENTES CAMPO TIPO LONG DESCRIPCI N Id Cliente VARCHAR 10 Identificador nico para el cliente Nombra VARCHAR 100 Dale completo del cliente o representante de la Empresa VARCHAR 50 Nombre de la Empresa del cliente Direccion VARCHAR 100 Direcci n principal de la empresa cliente Telefono VARCHAR 10 Tel fono del cliente Celular VARCHAR 15 Tel fono m vil del cliente Ciudad VARCHAR 50 Ciudad de residencia del cliente Departam VARCHAR 50 Departamento de residencia del cliente Email VARCHAR 20 Correo electr nico del cliente Tabla 17 Tabla Clientes Aplicaci n m vil Pascar Nombre Tabla M_TIPOS_DESCRIP_PROY e Des
154. zable Una SRS es trazable si el origen de cada uno de sus requisitos est claro y si facilita las referencias de cada requisito en el desarrollo futuro o documentaci n del mismo 2 4 2 4 Preparaci n Conjunta de la SRS El proceso de desarrollo de software debe empezar con un acuerdo entre el proveedor y el cliente en lo que el software debe hacer Este acuerdo en la forma de una SRS debe ser preparada conjuntamente Esto es importante porque ni el cliente ni el proveedor son calificables para escribir exclusivamente una buena SRS solos Por consiguiente el cliente y el proveedor deben trabajar juntos para producir una SRS completa y comprensible 17 2 4 2 5 La evoluci n de la SRS La SRS puede necesitar evolucionar en la medida en que avance el desarrollo del producto software Puede ser imposible especificar algunos detalles en el momento que el proyecto se inicia Los cambios adicionales pueden ocurrir de acuerdo a como se vayan descubriendo las deficiencias las limitaciones e inexactitudes en la SRS 2 4 2 6 Prototipos Los prototipos frecuentemente se usan durante una fase de los requisitos de un proyecto Existen muchas herramientas para generar un prototipo que exhiba algunas caracter sticas de un sistema creado r pida y f cilmente Los prototipos son tiles porque permiten desplegar algunos aspectos del sistema producir respuestas y generar nuevas preguntas Una SRS basada en un prototipo tiende a sufrir menos camb

pascar - Universidad Industrial de Santander

Contents

Download Pdf Manuals

Related Search

Related Contents