On Fri May 13 at 18:30:01 UTC 2016, Jakob Schlyter wrote: > Even a toolkit needs to take these issues into considerations.
Right, we don't need to start top down with a product (even though I think it's a great idea to do so). Is there any way of defining a subsystem or something like that which can be described architecturally and analysed? A component of a system can be seen as a product in it's own right, just that the requirements are derived from the parent level architecture and not user expectations. Is there an architecture document that would help me isolate the components currently under development and start there instead of with a user facing minimum viable product as the starting point? I really think it will save the project time if security requirements are set before large components are implemented, as changing things afterward is always painful and you never get as good an outcome. As to Peters opinion: is there a project charter or other document that defines the goals of the project or what the expected output is? I'm guessing the organisations sponsoring the project have some kind of idea about what they expect us to achieve? /olle _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
