Enrichment of Requirements Specifications with Videos
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 4 | |
| Author | 0000-0001-5336-6899 (ORCID) | |
| Contributors | 0000-0001-5336-6899 (ORCID) | |
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/19852 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Year | 2016 | |
| Production Place | Hannover |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
00:00
Streaming mediaPersonal digital assistantComputer scienceStreaming mediaStudent's t-testMathematical analysisLatent heatOcean currentTelecommunicationComputer configurationState of matterMereologyLecture/ConferenceMeeting/Interview
00:44
Streaming mediaThomas KuhnRecurrence relationMultiplication signMusical ensembleSoftware engineeringStreaming mediaMeeting/Interview
01:06
Raw image formatStreaming mediaRequirements engineeringBasis <Mathematik>SoftwareNatural languageLevel (video gaming)Metropolitan area networkRepresentation (politics)Content (media)InformationType theoryCharacteristic polynomialAsynchronous Transfer ModePresentation of a groupKolmogorov complexityMulti-agent systemStatement (computer science)Interface (computing)CASE <Informatik>Physical systemDiagramUser interfaceMachine visionProduct (business)Functional (mathematics)Context awarenessSoftware testingMathematicsBit rateGamma functionEmulationComputer configurationSystem identificationElectric currentZoom lensLengthFocus (optics)Flow separationData structure3 (number)Interactive televisionCohen's kappaMUDOpen sourceModal logicArmMaxima and minimaProduct (business)Natural languageForm (programming)Mobile appCombinational logicStreaming mediaOrder (biology)Web serviceLatent heatBitLevel (video gaming)Slide ruleOpen setGroup actionType theoryContent (media)Computer configurationMereologySound effectSoftware developerUser interfaceMachine visionSoftwareDifferent (Kate Ryan album)MassLengthTerm (mathematics)IBM Rational Unified ProcessIdentifiabilityNeuroinformatikInteractive televisionBit rateDivisorMultiplication signPhysical systemMathematicsData structureOnline helpBasis <Mathematik>Expert systemFunctional (mathematics)CASE <Informatik>Kolmogorov complexityTelecommunicationState of matterCharacteristic polynomialInformationRepresentation (politics)Observational studyAsynchronous Transfer ModeInterpreter (computing)WebsitePoint (geometry)Correlation and dependenceAreaGenderPattern languageLine (geometry)Flow separationArithmetic meanSystem callTexture mappingNichtlineares GleichungssystemFamilyTouch typingVirtual machineCorrespondence (mathematics)Internet forumE-learningVideo gameQuantumComputer animation
09:22
Metropolitan area networkArtificial neural networkStreaming mediaLengthMedianRequirements engineeringContent (media)Wide area networkSummierbarkeitRow (database)System identificationDivision (mathematics)Open setPerformance appraisalLevel (video gaming)Characteristic polynomialElectric currentHypothesisVector potentialRepresentation (politics)Thresholding (image processing)Uniform resource nameDemonExecution unitEmulationMIDISoftwareOrder (biology)Product (business)Streaming mediaContent (media)Object (grammar)Physical systemLatent heatUser interfaceVirtual machineThresholding (image processing)Computer configurationCharacteristic polynomialRepresentation (politics)Student's t-testLevel (video gaming)Universe (mathematics)Bit rateReal numberMappingPerformance appraisalLengthPresentation of a groupMathematicsSoftware developerPrototypeObservational studyMultiplication signDifferent (Kate Ryan album)MedianFile viewerPlanningInformationPoint (geometry)HypothesisTotal S.A.Flow separationOcean current1 (number)Structural loadView (database)DiagramElectronic program guideUsabilityRoundness (object)DialectArithmetic meanCASE <Informatik>RectifierReal-time operating systemFunctional (mathematics)Negative numberComputer animation
17:38
Streaming mediaLevel (video gaming)Medical imagingLatent heatInteractive televisionStreaming mediaData managementProcess (computing)TrailPoint (geometry)MathematicsMathematical analysisSoftware developerContent (media)Computer scienceDimensional analysisConnected spaceUser interfaceRight angleContext awarenessLogicDifferent (Kate Ryan album)NeuroinformatikProjective planePhysical systemComputer configurationSlide ruleMultiplication signTelecommunicationElectronic mailing listLie groupOrder (biology)View (database)Term (mathematics)ExistenceComputer animationMeeting/Interview
23:49
Streaming mediaVirtual machinePhysical systemoutputPoint (geometry)TouchscreenCASE <Informatik>Streaming mediaSoftware developerSoftwareInteractive televisionStaff (military)Texture mappingVirtual machineReading (process)WebsiteMereologyRepresentation (politics)Physical systemCASE <Informatik>Latent heatContext awarenessInjektivitätSubject indexingView (database)Markup languageDifferent (Kate Ryan album)Computer animation
25:47
Streaming mediaSoftware developerSoftware testingMedical imagingMeeting/Interview
Transcript: English(auto-generated)
00:00
It's Oliver Karas who will present the paper. Karas is a research assistant and a doctoral student at the Leibniz University here in Hannover. He has studied computer science. Currently his research considers the use of videos in technical specifications and this work is building
00:22
on his master thesis, two supported analysis or requirements workshop videos. He's interested in supporting requirements communication with appropriate documentation options to achieve better requirements comprehensibility for all involved stakeholders. So here it's getting specific and exciting I believe.
00:43
Please. Yeah, thank you. Yeah, I'm Oliver Karas. I'm from the software engineering group of Leibniz University in Hannover and today I want to talk about the usage of video in requirements engineering. Of course, I'm not sure if everybody knows what requirements engineering is.
01:01
I want to first give a little introduction. Corresponding to the definition of the IREP, yeah, the IREP International Requirements Engineering Board, requirements engineering is a systematic and disciplined approach to elicit, communicate and manage requirements. Requirements engineering forms the basis
01:21
for software development because we need to achieve a shared understanding between our customers and our developers in order to develop the correct, yeah, and satisfying and useful software product. One big aspect in requirements engineering
01:42
is the documentation of our requirements and a study to analyze different requirements documents, analyze that roundabout 80% of all content in such a specification is written in common natural language. The problem of this aspect is that it's not easy
02:03
to understand, you need a lot of interpretation often so it's abstract and not often completely clear. Furthermore, it's always a textual representation. It's quite difficult if we have to read 100, 200 sites in order to know what the software
02:21
our customer wants has to fulfill. Furthermore, we speak about complex and very interactive content between the user and the system under development. And additionally, in such a specifications there are many different information types with, yeah, different and interesting representation modes
02:46
which all have their own characteristics. This I will explain on the follow. In order to understand the complexity of such a requirement specification I want to give you an overview about general terms which are included in such a specification, sorry.
03:06
For example, there can be a mission state and a product vision scenario, use cases, functional requirements, non-functional requirements and all of these terms contain further detailed subterms. For example, non-functional requirements can be divided
03:21
into quality requirements, into technical requirements, into user interface requirements. Furthermore, for the complexity we have, as I mentioned the natural structure of formalized language where mainly the natural common language is used and we have text and graphics in order to represent visionary and interactive content.
03:44
Furthermore, all these aspects have characteristics of versioning, change rate, scope and a specific detailed level as is called in the requirements engineering which I will explain in the following. By all of these aspects such as specification document
04:01
is quite complicated to handle in order to understand what our customer wants and to develop the topic and the way he needs it. So why is video one possible option for us? AMBLER analyzed different kinds of documentation options regarding the communication channel,
04:21
sorry, regarding the richness of the communication channel and the communication effectiveness. Currently, we are using paper. As we can see, it's the lowest richness and the lowest effective documentation option of all. As we see, the best option is video,
04:41
but why don't we use video if it's the best option to document such things? Because we suffer from the same general problems as everyone. Video production has a high effort. The corresponding motivation to produce such a video is quite low and the usage in combination with a requirement specification is very cumbersome
05:00
because we have the written document or maybe in a digital form and the separate videos. As a first step in order to introduce videos, better in requirements engineering, our idea was that we want to help our requirements engineers in order to identify appropriate content for supplementary videos.
05:23
Therefore, we developed a starting set of guidelines based on the current research. First of all, we analyzed aspects of using or approaches of using videos in requirements engineering to understand which current approaches uses videos for which specific aspect.
05:44
Furthermore, there's the human computer interaction and the MOOCs, I think everybody knows, massive open online courses, who have a large experience based by using videos. Both research areas, MOOCs and HAT-CE, have a lot of different guidelines
06:00
in order to produce specific videos for use. For example, representing a user interface and how to use tutorials and lectures for such a course. By analyzing these different aspects and research areas, we developed our five guidelines as a first step
06:20
in order to help requirements engineers to understand or to identify how they can identify content which is appropriate for supplementary videos. First, very important aspect is the mentioned detail level, which I will explain in the following,
06:41
which should be quite low. It could sound a little bit strange why we should use low detail level, but we will see it on the next slide. Furthermore, yeah, easily visionary and interactive content is more appropriate for videos because videos have to show, as we have seen before,
07:01
movement and action in order that something must happen. The emerging video length is an important factor for us in the requirements engineering. I think it's an important factor for all because the users should watch the video in the whole length. Furthermore, we got the idea that representing the content
07:22
in a separate video is quite useful, which I'll also explain in the following slides. And one key aspect, it's not really to identify content, but as a guideline to support a video creation. We want a clear structure with the start,
07:41
mean part and the end in order to understand this part of content, which is represented. Because of the short time of 20 minutes, I want only to consider three aspects, the low detail level, the video lengths and the separate video in my following slides.
08:01
And first of all, let's start with the detail level. The so-called detail level is, yeah, a term created by Rup et al. We have to know Rup is a requirements engineer expert and they classified different content types in such a specification on the different levels.
08:23
And at this point, it's important to know that this detail level does not mean the amount of details within such a content. It further regards, yeah, I would say the art or the way of changing. Content of lower levels like visionary
08:41
and interactive content, for example, the visions and scenarios and use cases are also detailed information, but their changing rate is lower and there it is more appropriate to be supplemented by video. I want to explain it with a small example. So let's consider we have a vision of level two
09:01
and of level zero, sorry, and a requirement of level three. The vision could be sale tickets with vending machine. If I say today I want a vending machine, I will not say on the next day, it should be a mobile application or a web service on the other day. So the vision is stable and I easily can make a corresponding video
09:23
how a person buys something on a vending machine. Requirements and especially detailed requirements are really complicated. For example, the first requirement could be the system shall accept cash of 50 euro. Our developer reads this requirement and implements a software where you can only buy with 50 euro, everything.
09:44
Customer sees this prototype or this developed software and says, ah, no, sorry, that doesn't mean the system shall accept 50 euro. It shall accept cash from one coin up to 50 euro note. And this is a total other meaning, but he specified it not clearly enough.
10:02
Such a change happens really often. The study found out that 2% of all requirements in such a specification changed every month. For example, we work together with some larger industrial firms, for example, Continental, and they have about 2,000 requirements
10:22
in their specification. By 2%, these are 40 requirements that change every month. In the worst case, we have 40 videos. For these requirements as they change, we have to create 80 videos. The effort will increase even more and therefore we have to focus first on the low level details
10:41
in order to use this content to support it by video. Toward the video length. At first, I have to define a term, it's called engagement time. And this means the length of time a user is spending by watching a video. A study of Google at R analyzed a set
11:02
of a lot of different MOOC videos and they found out that the median engagement time, regardless to the total video length, is six minutes. So a user skips a video after around about six minutes and will not watch the end if it's longer, for example, nine to 12 minutes.
11:23
Furthermore, in the below diagram, they normalize the engagement time to what the video lengths. And they found out that videos with a length of nine minutes and longer are only watched up to 60%. So if we make two large videos,
11:42
the viewers are not willing to watch the whole video and if we put requirements at the end, they would not find it, they would not understand it and this information would be lost. For requirements engineering, as I mentioned,
12:00
we have extensive and complex content. So if we use videos, the content has to what we watched or to be written by multiple times and also the video should be used multiple times. Therefore, we need a high engagement time so the viewers, for example, our developers, will watch the video in total.
12:21
And this requires short videos in order to fulfill the required high engagement time. Towards the last point of separate videos, I have a small example of how such videos for the specification of their content can be used. There are different possible viewers.
12:40
We can have our developers, we can have our user interface designers, our customers or our software architects. And all of them have individual needs. They do not need to watch all videos and to read all content in such a specification, but we need specific one. So if we put one content in one video, we have autonomy and we can easily identify
13:02
the content represented by the video. Therefore, we achieve an overview and each possible viewer can easily find what he needs. On the other hand, if we put multiple content in one video, we get the problem that the effort of our viewers increase because they have to find the point in the video
13:21
where the important information is and this reduce their further motivation to use such videos. Now I want to give you a little, yeah, overview about our plan of future work regarding the use of videos and requirements engineering.
13:40
There are current other open issues. For example, the high detail level. We considered only the low detail level because of the lower changing rate. But we could imagine that there are one or two important requirements for video requirements of the higher detail levels, which are so important to be understand
14:01
that the effort of making a video could be very useful and it could be of value for us in order to understand the system, what to do and to develop the system in a correct way. Furthermore, requirements have a lot of other characteristics. For example, priority or legal obligation.
14:23
Priority means how important is this feature, this function, this requirement for our customer. The higher importance of a requirement could indicate that the use of video is more appropriate since if we understand this high important aspect
14:44
for our customer, it is better to develop the required or the desired system. The legal obligation clarifies if a requirement is a must-have or an optional aspect.
15:01
And therefore, for example, it is very obvious that must-haves should be more suitable or appropriate for video than optionals. At all, we want to refine our guideline set, where we have here only a starting set as mentioned.
15:21
And this is the current topic of a master thesis. A student of our university is analyzing different kind of requirements specification and tries to find out a mapping between the content and which type of video and how it could be produced. At the end, we want to understand
15:43
how usable these guidelines really are by real requirement engineers. So we strive for an evaluation of our guidelines to understand if they are useful, if they are understandable and if we can reach our aim to support the creation of video.
16:01
So I want to give you a last little conclusion of what we've seen. So requirements engineering actually use textual documentation to specify a software product. Such representation is very abstract, incomprehensible, seldom complete and accurate.
16:23
Videos offers a potential to represent specific content in a better way and to achieve a better understanding and therefore to enhance the comprehensibility of requirements. We suffer from the same general problems, high production effort, low motivation.
16:42
And therefore we came to the idea of offering a starting set of guidelines to identify in the first step the appropriate content which could be supplemented by video in order to lower the threshold of effort to know what should I represent at all of my specification of my requirements by video.
17:03
Our higher objective is the use of videos as supplementary material for requirements specification content in order to achieve a higher understanding between our customer or a better understanding between our customers and our developers to develop and implement as a satisfying and useful software product to customer needs.
17:23
And now I'm at the end of my presentation. I thank you for your interest and I'm very excited if you have questions. Thank you.
17:43
While you are reflecting, I think I take a question myself. So are there some industries which are more likely to start using these than others or do you see some tendencies already? Ten, please. Not at all. I work together with someone in the Swiss
18:01
and there's a telecommunication firm, Swisscom, and they are interested in integrating videos in their development process. So we are hopeful that by this contact we can get further deeper knowledge about what they want to do with the videos
18:22
and if it's the same way as we thought of it. In research, there are a lot of different aspects in requirements engineering how videos can be used. But the problem is that all these aspects or approaches use videos only to communicate, manage or document some kind of requirements
18:44
for one specific aspect and say, do not think about the further use of videos. All approaches offer effort in order to create videos for specific use.
19:01
But after this, use is not further important for the process. And if we can map content of all specifications to such a video, it could be further used in other aspects of the software development at all.
19:26
Thank you for your talk. It's a very good idea to illustrate requirement specifications with videos. I like that very much. I expect that you would first finish the requirement specification and then produce the video.
19:43
However, it's quite normal that you have to modify the requirement specification over and over again. So my question is how do you react to that with regard to your produced video? This is the same point as a detail level. Changing a requirement is the same as changing a specification
20:02
is the same as changing one requirement. And therefore, the lower detail levels are first important. Our idea is not based on writing the specification and producing videos afterwards, but combining it in a way if we have the requirement, we want an approach at the end,
20:24
which allows us easily and fast making a video and adding it to such a specification or specific content of it. And this problem of managing and changing is a large problem.
20:42
And we think about making the first step by showing people the option, how they can maybe connect content with video. And then we have further to look how we can manage and change and how we can manage such a change
21:01
between specifications and videos that exists. So I cannot clearly give you an answer to your question. This is a problem. I think if you find the right solution, you can get easily a PhD in informatics or computer science. We have currently a research project
21:24
where we want to consider firstly, the use of videos. And as we outlined in our future work, we would then, if we see useful, yeah, possible options to use such videos, the management and the connection
21:41
between these two aspects of specification and content. And I think I, at this point, I have also to mention requirements. Engineering is only a larger, a general term. It's divides and requirements analysis where we get this requirements rights and documentation and some management process after that,
22:01
where we have to reflect changes, get to know what is the price if we want to change something in the system we have defined before. And such a change of existence specification would be an aspect of requirements management and not of requirements analysis
22:21
where we are currently working on. Yeah. Yeah, it could be quite a nice idea. I also thought about some usage of, yeah,
22:43
videos which are representing the user interface. It's clearly a static image, first of all, which gets the interaction by clicking and highlighting only some aspects. And my idea could be if this image only changes and we have the same image at all
23:01
and need only to know where the interaction points have to be placed in the video, we could easily exchange the background at all of the video and keep a track of the click, the mouse movements and so on. And this could be also an aspect of how videos in usage could be easily changed and merged.
23:31
Okay, so it seems that there are no more questions at this point. If it's allowed, I would show you one more slide of my annex because I was not sure
23:41
if I got it all in the time. It should only represent how videos could be used in specifications. At the left side, we see only a part of a use case which describes the interaction between the system and the user. And this interaction and this representation
24:01
is standard in requirement specification. We have a lot of staff and in interaction, the system do something, the user do something and the developers have to read it and to understand it and implement the software accordingly. And our idea is that we could use this by an easy video.
24:20
For example, here it's with an existing machine. The same steps only represented by the video and the usage. And now the system has shown the start screen, the user selected start and aim. Now he's selected, okay, I was so sorry.
24:40
He have done the same steps in this texture representation, what we've seen in the video. And our idea is that this could be more comprehensible to develop us instead of reading and interpreting the written context, yes.
25:09
If you are familiar with, for example, mock-up software like Balsamiq. Yeah. Where you basically have kind of sketch representation but it's clickable and so on.
25:20
So what you can do is you built your website as a mock-up in a software like Balsamiq and then you film the interact, you kind of create a video of the interaction with the mock-up that you have made. So basically what we do, we don't write this textural stuff because it takes too long. So basically we create the mock-up and then we film us interacting with the mock-up
25:41
as kind of an explanation of the mock-up that we have produced. So it's some kind of agile software development. It's agile software development. And we are talking about classical requirements engineering. We're doing agile anyway. Agile is a new, thank you.