Main goal of this paper is to define a solution for employee training and development programs. The goal is accomplished through formulating of project management plan and specifications of requirements and software architecture.

Målet med examensarbetet var att ta fram en kravspecifikation till KTH:s och ICT:s webbportal avseende utökning av tjänster för förmedling av sommarjobb, mentorskap, studiebesök och projektidéer. Syftet är att beskriva hur de fyra tjänsterna kan fungera i interaktionen mellan användaren och webbportalen. Det hela sammanställdes i en kravspecifikation med hjälp av användarfall. Metoden som valdes för att genomföra arbetet var aktionsforskning. Första steget i metoden var att studera webbportalen och sedan genom intervjuer och diskussioner ta fram användarfallen. Analysen av resultaten visar att ingenting saknas gällande funktionaliteten hos tjänsterna, men det skulle vara bra med ytterligare validering genom att diskutera kravspecifikationen med någon kunnig inom användarfall. / The goal of this paper was to produce a requirements specification for KTH:s and ICT:s web portal regarding the extension of the services intermediation of summer job, mentoring, study visits and project ideas. The purpose of the paper is to describe how the four services can function in the interaction between the user and the web portal. This was compiled into a requirements specification consisting of a number of use cases. The method chosen to conduct the research was action research. The first step of the method was to study the web portal and then through interviews and discussions create the use cases. The analysis of the results shows that nothing is missing regarding the functionality of the services, but it would be good with further validation by discussing the requirements specification with someone knowledgeable in the field of use cases.

Software intensive systems are developed to provide solutions in some problem domain and software engineering principles are employed to develop and implement that system. Software engineering principles should enhance the development and production of software artifacts and yet the artifacts often lack in quality. Crucial in the development process are requirements engineering activities and methods for software documentation. This research focused on requirements engineering activities, software requirements documentation and employed a new approach in these activities that incorporated ontology engineering principles. Ontology engineering refers to the set of activities concerned with the ontology development process, the ontology life cycle, the methods for building ontologies, and the tool suites and languages that support them. Ontologies facilitate domain knowledge reuse and sharing and provides a common vocabulary to system developers. The motivation of this research came from Ambr´osio and Kaiya, advocating the definition of the Software Requirements Knowledge Area of the Software Engineering Body of Knowledge (SWEBOK ) within an ontology system. The resulting system utilized the benefits of intelligent reasoning to elicit, automatically verify, extract and document software requirements. The requirements engineering process was modeled in an ontology. An ontology is a machine-readable data structure that distinctly defines concepts and describes relationships among those concepts. The requirements engineering process and ontology were the focal points in this research. A baseline ontology for software requirements engineering was created. The following are contributions of this research. A methodology was designed to enhance the software documentation production process. An initial ontology model of SWEBOK recommended data items was created. A method was provided to verify software requirements as they were elicited, entered and maintained in an ontology. A method was created that electronically provided provenance of software requirements. Software was created to automatically extract the software requirements from within an ontology.

Assurance Cases have been effectively used for improving the safety of real-time safety systems. However, until now, Assurance Case techniques have not been applied to building confidence in the correctness of Scientific Computing (SC) software. Our approach is to employ Assurance Case techniques to the case of a specific medical image analysis software, 3dfim+, and then generalize the results/template for other medical and SC software. Using the Goal Structuring Notation (GSN), we develop an Assurance Case to support the top goal that "Program 3dfim+ delivers correct outputs when used for its intended use/purpose in its intended environment." This claim is supported by several sub-claims, including the claims that high-quality requirements exist and that the implementation complies with the requirements. The full argument decomposes each sub-claim further until at the bottom level evidence is provided. The evidence provided includes the requirements documentation, test cases and expert review. To simplify the Assurance Case diagram, a new generic module, parameterized over quality, was developed to argue that each quality has been achieved. Evaluation of the full Assurance Case shows that this approach is feasible for building confidence in SC software, even in the practical situation where confidence is sought, but redesign and reimplementation are not possible. The exercise uncovered issues with the original documentation for 3dfim+, including missing assumptions, and ambiguity with the chosen sign convention. Furthermore, although no errors in output were found, the Assurance Case highlights that confidence in the original 3dfim+ software could be improved through additional checks for input validity. / Thesis / Master of Science (MSc)

Despite advancements in requirements generation models, methods and tools, low quality requirements are still being produced. One potential avenue for addressing this problem is to provide the requirements engineer with an interactive environment that leads (or guides) him/her through a structured set of integrated activities that foster "good" quality requirements. While that is our ultimate goal, a necessary first step in developing such an environment is to create a formal specification mechanism for characterizing the structure, process flow and activities inherent to the requirements generation process. In turn, such specifications can serve as a basis for developing an interactive environment supporting requirements engineering. Reflecting the above need, we have developed a markup language, the Requirements Generation Markup Language (RGML), which can be used to characterize a requirements generation process. The RGML can describe process structure, flow of control, and individual activities. Within activities, the RGML supports the characterization of application instantiation, the use of templates and the production of artifacts. The RGML can also describe temporal control within a process as well as conditional expressions that control if and when various activity scenarios will be executed. The language is expressively powerful, yet flexible in its characterization capabilities, and thereby, provides the capability to describe a wide spectrum of different requirements generation processes. / Master of Science

An increasing number of software systems must safeguard their confidential data and code, referred to as critical program information (CPI). Such safeguarding is commonly accomplished by isolating CPI in a trusted execution environment (TEE), with the isolated CPI becoming a trusted computing base (TCB). TEE protection incurs heavy performance costs, as TEE-based functionality is expensive to both invoke and execute. Despite these costs, projects that use TEEs tend to have unnecessarily large TCBs. As based on our analysis, developers often put code and data into TEE for convenience rather than protection reasons, thus not only compromising performance but also reducing the effectiveness of TEE protection. In order for TEEs to provide maximum benefits for protecting CPI, their usage must be systematically incorporated into the entire software engineering process, starting from Requirements Engineering. To address this problem, we present a novel approach that incorporates TEEs in the Requirements Engineering phase by using natural language processing (NLP) to classify those software requirements that are security critical and should be isolated in TEE. Our approach takes as input a requirements specification and outputs a list of annotated software requirements. The annotations recommend to the developer which corresponding features comprise CPI that should be protected in a TEE. Our evaluation results indicate that our approach identifies CPI with a high degree of accuracy to incorporate safeguarding CPI into Requirements Engineering. / Master of Science / An increasing number of software systems must safeguard their confidential data like passwords, payment information, personal details, etc. This confidential information is commonly protected using a Trusted Execution Environment (TEE), an isolated environment provided by either the existing processor or separate hardware that interacts with the operating system to secure sensitive data and code. Unfortunately, TEE protection incurs heavy performance costs, with TEEs being slower than modern processors and frequent communication between the system and the TEE incurring heavy performance overhead. We discovered that developers often put code and data into TEE for convenience rather than protection purposes, thus not only hurting performance but also reducing the effectiveness of TEE protection. By thoroughly examining a project's features in the Requirements Engineering phase, which defines the project's functionalities, developers would be able to understand which features handle confidential data. To that end, we present a novel approach that incorporates TEEs in the Requirements Engineering phase by means of Natural Language Processing (NLP) tools to categorize the project requirements that may warrant TEE protection. Our approach takes as input a project's requirements and outputs a list of categorized requirements defining which requirements are likely to make use of confidential information. Our evaluation results indicate that our approach performs this categorization with a high degree of accuracy to incorporate safeguarding the confidentiality related features in the Requirements Engineering phase.

Syfte: Uppsatsens syfte är att tillföra förståelse och kunskap för hur rekryteringskonsulter arbetar med att definiera och bedöma personliga egenskaper som inkluderas i en kravspecifikation. Vidare vill vi kartlägga de verktyg som rekryteringskonsulter använder för att utföra denna bedömning. En större förståelse för dessa processer och begrepp kan skapa ökad medvetenhet och i förlängningen professionalisering av både företag och rekryterare, och framför allt i kommunikationen dem emellan.Metodik: Vi har använt oss av en deduktiv ansats och en kvalitativ forskningsmetod. Vi har utfört elva kvalitativa och semistrukturerade intervjuer med elva personer aktiva inom rekryteringsbranschen.Resultat: Vi har uppmärksammat att rekryteringskonsulter finner en svårighet med att definiera de personliga egenskaperna i en kravspecifikation. Orsakerna har preciserats bero på en kommunikationsbrist mellan rekryteringskonsult och kundföretag. En bristande kommunikation resulterar i att definitionen av de personliga egenskaperna inte är överensstämmande mellan parterna, vilket försvårar rekryterarens arbete med att finna den rätta medarbetaren. Vi har kommit fram till att ett fysiskt möte skapar möjligheten för rekryteringskonsult och kundföretag att nå en god kommunikation. Den goda kommunikationen har i sin tur visats vara det verktyg som minskar risken för att en tolkningsvariation ska uppstå. / Purpose: The purpose of the essay is to provide an understanding and knowledge of how recruitment consultants work to define and assess personal qualities that are included in a requirement specification. Furthermore, we want map the tools that recruitment consultants uses to perform this assessment. A greater understanding of these processes and concepts can create an increased awareness and, in the long run, professionalization of both companies and recruiters, especially in the communication between them.Method: We have used a deductive and qualitative research approach. We conducted eleven qualitative and semi-structured interviews with people working within the recruitment industry.Conclusion: We have seen that recruitment consultants find it difficult to define the personal characteristics found in a requirement specification. The reasons are clarified to be due to the lack of communication between the recruitment consultant and the customer. A lack of communication results in the fact that the definition of the personal characteristics is not consistent between the parties, which significantly complicates the recruitment consultant’s work to find the right employee. We have therefore come to the conclusion that a physical meeting creates the opportunity for recruitment consultants and customers to achieve a good communication. The good communication has, in turn, been shown to be the way to reduce the risk of a definition variation.

<p>Systems development projects and their documents are more or less standardized and can mainly be applied on systems that are supposed to be built from scratch, or updated. In pace with the number of IT-systems are increasing worldwide there is no need for every organization to build their own IT-system. Nowadays it is also possible to purchase licenses which allow the purchaser to modify or add functions to the system. Along with those changes, there have been an increased amount of “rapid development methods” such as Agile and “Quick and Dirty” solutions, but these methods and perspectives are mainly focusing on entire systems development processes, as the old ones, but quicker.</p><p>If a company purchases an off-the-shelf system with source code available, there is no real need to go through a proper systems development process. During interviews with a small company that has acquired a system as mentioned above, the researcher realized that only one single document is needed, the requirements specification. Today’s requirements specifications can be either well detailed or less, but a project still needs the details specified. Combining a known agile development process with IEEE’s standardized requirements specification, a new way to proceed with projects based on one single document (the requirements specification) has been made. This document also has a focus on simplicity for the inexperienced readers, but with the depth that every developer has got a use for.</p>

Made available in DSpace on 2015-05-14T12:36:31Z (GMT). No. of bitstreams: 1 arquivototal.pdf: 5528255 bytes, checksum: a0288caf46be4569d85b7a218a0a4dc7 (MD5) Previous issue date: 2011-11-21 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - CAPES / The addition of software to TV programs through the implantation of the Brazilian Digital TV boosted the integration of these two major industries: software and TV. These two directions have different thoughts and ways of working, however, with the release of the Digital TV these two professional, communication and information technology need to work together. The software requirements specification follows some of the activities defined in accordance with the procedure being used. In digital television requirements elicitation, we find a different environment in which there are several professional profiles involved in this activity. This research present an agile process for requirements specification in interactive programs that integrate audiovisual content and interactive applications, in order to facilitate understanding and development of the interactive program by the team involved. The approach presented is based on a screenplay and interactive user stories. The interactive script will add the interactive application information to the communication team script and the storyboard will facilitate the understanding of the application. The process was used in a real project, where twelve interactive programs were developed. Finally, we discuss the results and perspectives. / A adição de software aos programas de TV através da implantação do Sistema Brasileiro de TV Digital impulsionou a integração dessas duas grandes indústrias: software e TV. Essas duas linhas de trabalho possuem diferentes pensamentos e formas de trabalhar, contudo, com a chegada da TV Digital estes dois perfis profissionais, comunicação e informática necessitam trabalhar juntos. A especificação de requisitos do software segue algumas atividades determinadas de acordo com o processo que está sendo utilizado. Na televisão digital a elicitação de requisitos encontra um ambiente diferente, no qual, temos perfis profissionais diversos que estão envolvidos nesta atividade. Neste trabalho apresentamos um processo ágil para a especificação de requisitos em programas interativos que integram conteúdo audiovisual e aplicações interativas, buscando facilitar o entendimento e desenvolvimento do programa interativo pela equipe envolvida. A abordagem apresentada é baseada em roteiro interativo e histórias de usuário. O roteiro interativo vai adicionar as informações da aplicação interativa ao roteiro da equipe de comunicação e, o storyboard irá facilitar o entendimento da aplicação. O processo foi utilizado em um projeto real, onde doze programas interativos foram desenvolvidos. Por fim, são discutidos os resultados obtidos e perspectivas.

Systems development projects and their documents are more or less standardized and can mainly be applied on systems that are supposed to be built from scratch, or updated. In pace with the number of IT-systems are increasing worldwide there is no need for every organization to build their own IT-system. Nowadays it is also possible to purchase licenses which allow the purchaser to modify or add functions to the system. Along with those changes, there have been an increased amount of “rapid development methods” such as Agile and “Quick and Dirty” solutions, but these methods and perspectives are mainly focusing on entire systems development processes, as the old ones, but quicker. If a company purchases an off-the-shelf system with source code available, there is no real need to go through a proper systems development process. During interviews with a small company that has acquired a system as mentioned above, the researcher realized that only one single document is needed, the requirements specification. Today’s requirements specifications can be either well detailed or less, but a project still needs the details specified. Combining a known agile development process with IEEE’s standardized requirements specification, a new way to proceed with projects based on one single document (the requirements specification) has been made. This document also has a focus on simplicity for the inexperienced readers, but with the depth that every developer has got a use for.