class: center, middle
Helge Pfeiffer, Assistant Professor,
Research Center for Government IT,
IT University of Copenhagen, Denmark
[email protected]
class: center, middle
- Assignments 1 to 5 are mandatory
- Assignment 0:
- was not mandatory
- 73 of 138 students handed-in, hmmm
- Hand-in requirement was: Link to GitHub repository with PDF in it.
- A link to an Overleaf project is not a PDF file.
- Idea was that everybody hands-in to train the hand-in process :)
--
- Hand-in requirements for Assignment 01, see https://github.com/itu-bdsa/assignment-01/#submitting-the-assignment and every member of the assignment groups has to hand-in!
class: center, middle
requirement
statement which translates or expresses a need and its associated constraints (3.1.7) and conditions (3.1.6)
Note 1 to entry: Requirements exist at different levels in the system structure.
Note 2 to entry: A requirement is an expression of one or more particular needs in a very specific, precise and unambiguous manner.
Note 3 to entry: A requirement always relates to a system, software or service, or other item of interest.
--
software requirements specification (SRS). (1) documentation of the essential requirements (functions, performance, design constraints, and attributes) of the software and its external interfaces
IEEE 1012-2016 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1.29
- Navigate to https://menti.com
- Login to quiz with code: 4425 3618
If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not predefined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.
A. M. Davis "Software Requirements: Objects, Functions and States."
A common problem with non-functional requirements is that stakeholders propose requirements as general goals, such as ease of use, the ability of the system to recover from failure, or rapid user response. Goals set out good intentions but cause problems for system developers as they leave scope for interpretation and subsequent dispute once the system is delivered.
Whenever possible, you should write non-functional requirements quantitatively so that they can be objectively tested.
Sommerville "Software Engineering" (10th Ed.)
- Funktionelt (forretningskrav).
- Ikke-funktionelt (løsningsorienterede krav).
- Lov og politik (lovmæssige og politiske krav til Systemet)
Divided into:
- Minimumskrav (MK)
- Krav (K)
- Option (O)
Non-functional requirements may affect the overall architecture of a system
Sommerville "Software Engineering" (10th Ed.)
--
The Sags- og Partsoverblik (SAPA) system has a complete requirements specification document before any work on the system started.
Does it have to be like that?
--
Depends on the kind of project and its contract.
Ideally, the functional requirements specification of a system should be both complete and consistent. Completeness means that all services and information required by the user should be defined. Consistency means that requirements should not be contradictory.
Sommerville "Software Engineering" (10th Ed.)
--
I forbindelse med EU-udbud har kunden, som en del af udbudsmaterialet, fremlagt denne del af leverancebeskrivelsen, som består af kundens kravspecifikation. I det omfang leverandøren ikke opfylder kravspecifikationen ved den tilbudte løsning, skal leverandøren i sit tilbud foretage ændringer i kravspecifikationen, således at der i tilbudet er fuld overensstemmelse mellem kravspecifikationen og løsningsbeskrivelsen. Leverandørens ændringer vil herefter inden for tildelingskriterierne indgå som del af kundens vurdering af de afgivne tilbud.
[...] Kundens kravspecifikation skal indeholde alle kundens krav til leverancen.
Bilag til K02 Standardkontrakt for længerevarende IT-projekt
--
Gennemførelsesfasen: Projektets leverancer udvikles og leveres. Det er i denne fase, at projektet foretager kravspecifikation, udbud og udvikling af leverancer samt den organisatoriske og tekniske implementering. Der følges op på tidlige indikatorer for gevinster, og dele af gevinstrealiseringen kan være i gang. Projektgrundlaget og business casen opdateres fortsat, og projektet skal statusrapportere til Statens It-råd.
Leverancebeskrivelsens udvikling
Leverandøren skal ved opfyldelsen af Kontrakten levere en ydelse, der frembringes agilt uden at modtage en komplet kravspecifikation. Leverancebeskrivelsen fastlægger således Kontraktens Omfang, men indeholder ved Kontraktens indgåelse ikke alle de detaljerede krav til løsningen.
[...] Ved Kontraktens indgåelse er kravene til løsningen overordnet og behovsorienteret formuleret. Kravene nedbrydes og detaljeres herefter løbende.
K03 Standardkontrakt for længerevarende IT-projekt baseret på en agil metode Bilag
--
An example of a successful contract is one I negotiated for a large, multiyear, half-million-line project in 1994. We, the development team, were paid a relatively low monthly rate. Large payouts were made to us when we delivered certain large blocks of functionality. Those blocks were not specified in detail by the contract. Rather, the contract stated that the payout would be made for a block when the block passed the customer’s acceptance test. The details of those acceptance tests were not specified in the contract.
Robert C. "Martin Agile Principles, Patterns, and Practices in C#"
Patients whose information is recorded in the system and relatives of these patients.
Doctors who are responsible for assessing and treating patients.
Nurses who coordinate the consultations with doctors and administer some treatments.
Medical receptionists who manage patients’ appointments.
IT staff who are responsible for installing and maintaining the system.
A medical ethics manager who must ensure that the system meets current ethical guidelines for patient care.
Health care managers who obtain management information from the system.
Medical records staff who are responsible for ensuring that system information can be maintained and preserved, and that record keeping procedures have been properly implemented.
Sommerville "Software Engineering" (10th Ed.)
--
Stakeholders range from end-users of a system through managers to external stakeholders such as regulators, who certify the acceptability of the system.
System stakeholders include anyone who is affected by the system in some way and so anyone who has a legitimate interest in it.
Sommerville "Software Engineering" (10th Ed.)
That is real: See evolution of requirements specification of KOMBIT's SAPA system https://share-komm.kombit.dk/P011/Delte%20dokumenter/Forms/KS.aspx
Requirements engineering is usually presented as the first stage of the software engineering process. However, some understanding of the system requirements may have to be developed before a decision is made to go ahead with the procurement or development of a system. This early-stage RE establishes a high-level view of what the system might do and the benefits that it might provide. These may then be considered in a feasibility study, which tries to assess whether or not the system is technically and financially feasible.
Sommerville "Software Engineering" (10th Ed.)
- You for a company that sells something to a client.
- A client for the company.
- Some hybrid of the above.
class: center, middle
|
What is the meaning of:
|
|
|
What is the major issue with this use case diagram from Sommerville compared to the two previous use case diagrams?
You read in Sommerville about requirements specification via structured natural language. Let's have a look on how these could look like in case of the requirements specification document of the Sags- og Partsoverblik (SAPA) system.
--
<iframe src="material/Kravspecifikation juli 2014 v. 1.0.pdf" width="100%" height=600 scrolling="auto"></iframe>
<iframe src="material/Kravspecifikation juli 2014 v. 1.0.pdf" width="100%" height=600 scrolling="auto"></iframe>
use case.
(1) in UML, a complete task of a system that provides a measurable result of value for an actor
ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary
(2) description of behavioral requirements of a system and its interaction with a user
(3) specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system Note: More formally, a use case defines a set of use case instances or scenarios.
scenario
- step-by-step description of a series of events that occur concurrently or sequentially cf. use case Note: A scenario can be a user story, use case, operational concept, or sequence of events the software may encounter.
ISO/IEC/IEEE 24765:2017(en) Systems and software engineering — Vocabulary
--
operational scenario
- description of an imagined sequence of events that includes the interaction of the product or service with its environment and users, as well as interaction among its product or service components
Note: Operational scenarios are used to evaluate the requirements and design of the system and to verify and validate the system.
Multiple requirements per use case for SAPA requirements specification document.
<iframe src="material/Kravspecifikation juli 2014 v. 1.0.pdf" width="100%" height=600 scrolling="auto"></iframe>Watch the video below and assume that the narrator tells you about an envisioned system, not one that already exists:
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/XYGubkLrRtA" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>-
Identify three requirements that a spreadsheet application should fulfill
-
Does the narrator describe user or system requirements?
-
List names of use cases.
-
Do that on https://menti.com
-
Login to quiz with code: 84 13 23 4
- Kommunernes Pensionssystem (Social Pension)
- Fællesoffentlig Elektronisk Sags- og Dokumenthåndtering
- Samlet socialfagligt it-system
- Det Nationale Indikator Projekt IT system
- Proces- og Dokumentstyringssystem
- Go to the exercise session.
- Work in your assignment triplet, see https://github.com/itu-bdsa/assignment-01/README_GROUPS.md
- Work on the exercises of the assignment, see https://github.com/itu-bdsa/assignment-01/README.md
Via LearnIT Hand-in, hand-in a link to the Git repository on GitHub with your solution, at latest on Friday at 10:00.