Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]
pdfs.semanticscholar.org
Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]
1–10 of 40 posts
Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]
#2Can anyone recommend any links/articles/books about the relationships between specification, implementation, testing, provability, TDD, BDD, etc.?
I have been working on designing some software for improving the specifications process, and quickly realized that it's a very interconnected concept: the specification can be treated very formally, leading to things like BDD (behavior-driven development), but also to things like formal provability.
I'm generally interested in the relationships/processes that mediate between design specification actual programming. In reality, there's a lot of feedback, and I want to create ways of radically improving these processes.
Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]
#3Can anyone recommend any links/articles/books about the relationships between specification, implementation, testing, provability, TDD, BDD, etc.? I have been working on designing some software for improving the specifications process, and quickly realized that it's a very interconnected concept: the specification can be treated very formally, leading to things like BDD (behavior-driven development), but also to thin…
You might be interested in this study as a way of refining your interests and goals:
http://loonwerks.com/publications/pdf/cofer2013fmics.pdf
It's a big world out there; this has been an active area of research basically since Turing. Many of the "relationship between" questions you ask have their own conference or workshop series.
> formal provability
IMO the best way to start down this road is to just begin using some of the tools out there -- TLA+, Coq, whatever - and touch base with the community around your choice of tool (conferences, workshops, or even going back to school for a phd). The best way to learn about the strengths and limitations of current software practice is to sit down and churn out code, preferably with a strong mentor. The same is true for proof programming.
Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]
#4Can anyone recommend any links/articles/books about the relationships between specification, implementation, testing, provability, TDD, BDD, etc.? I have been working on designing some software for improving the specifications process, and quickly realized that it's a very interconnected concept: the specification can be treated very formally, leading to things like BDD (behavior-driven development), but also to thin…
It looks like you are looking for the V-Model development process used in the industry (e.g. automotive).
A typical requirement in this model is handled like this: 1. the high level specification define what is the change about (e.g. implement a hillholder function). 2. architecture phase: you identify which part/module of the system are impacted by the high level requirement. You define what each part will do and you specify how they interface. 3. detailed design phase: each part is formally specified, in the automotive industry we typically use Model based development (Simulink) to specify this phase. 4. implementation: actual coding being done, if you use Simulink this is done by the Simulink/dSpace. A unit test is then performed to check that the detailed design from part 3 has been correctly done. 5. Integration and test: all parts are collected and compiled, and we look that the interfaces are matching. 6. System test: all parts are now tested together against the specifications done in the architecture phase (part 2) and part 1
In the automotive industry, each step can be done by a different person/team/company thus the documentation done in each phase is extremely important to avoid finger pointing in case a problem is detected after delivery.
Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]
#5Can anyone recommend any links/articles/books about the relationships between specification, implementation, testing, provability, TDD, BDD, etc.? I have been working on designing some software for improving the specifications process, and quickly realized that it's a very interconnected concept: the specification can be treated very formally, leading to things like BDD (behavior-driven development), but also to thin…
If you search for the SEL4 kernel, or the L4 family in general, there's a fair number of papers and presentations on their activity in this area. I don't know if I would characterize it as a particularly fast development process though.
Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]
#6Can anyone recommend any links/articles/books about the relationships between specification, implementation, testing, provability, TDD, BDD, etc.? I have been working on designing some software for improving the specifications process, and quickly realized that it's a very interconnected concept: the specification can be treated very formally, leading to things like BDD (behavior-driven development), but also to thin…
It looks like you are looking for the V-Model development process used in the industry (e.g. automotive). A typical requirement in this model is handled like this: 1. the high level specification define what is the change about (e.g. implement a hillholder function). 2. architecture phase: you identify which part/module of the system are impacted by the high level requirement. You define what each part will do and yo…
Excellent, I knew there had to be a ton of history here, but I hadn't known about this specifically. Thank you!
Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]
#7Can anyone recommend any links/articles/books about the relationships between specification, implementation, testing, provability, TDD, BDD, etc.? I have been working on designing some software for improving the specifications process, and quickly realized that it's a very interconnected concept: the specification can be treated very formally, leading to things like BDD (behavior-driven development), but also to thin…
It looks like you are looking for the V-Model development process used in the industry (e.g. automotive). A typical requirement in this model is handled like this: 1. the high level specification define what is the change about (e.g. implement a hillholder function). 2. architecture phase: you identify which part/module of the system are impacted by the high level requirement. You define what each part will do and yo…
Oh—also—do you know what software out there is already used for managing this complexity? Thanks again!
Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]
#8Strange how whatever Adrian Colyer covers in his The Morning Paper makes its way here. People perfer posting the original paper rather than his blogs posts.
Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]
#9Earlier quoted context omitted.
It looks like you are looking for the V-Model development process used in the industry (e.g. automotive). A typical requirement in this model is handled like this: 1. the high level specification define what is the change about (e.g. implement a hillholder function). 2. architecture phase: you identify which part/module of the system are impacted by the high level requirement. You define what each part will do and yo…
Oh—also—do you know what software out there is already used for managing this complexity? Thanks again!
I think Product Lifecycle Management (PLM) is the buzzword your looking for.
Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]
#10Earlier quoted context omitted.
Oh—also—do you know what software out there is already used for managing this complexity? Thanks again!
I think Product Lifecycle Management (PLM) is the buzzword your looking for.
PLM I'm familiar with, though none of the ones I've seen seem to focus in any particular was on the requirements/specification end of the equation...