I am writing a user requirements document for a standalone application.
The application is supposed to help to look for files on archives.
I have the following structure of the document :
Introduction
Functional needs .
Functionals of the system
UI
Non functional needs
is it sufficient ? Do you know other parts that I can add ? Do I write "Project management timing" ?
I would suggest the following structure:
Introduction -
including Executive Summary, General Assumptions & Design Guidelines, Prioritization guidelines, Purpose of Document
The product personas
The product domains
The product interfaces (possible external and internal)
Supported scenarios and End to End flows.
Functional requirements
Security considerations.
Non functional requirements - including performance, scalability, resilience
Related
I spent short time studing Habanero and i found it good approach for making Enterprise Application in a really short period of time.
The pattern witch Habanero use is "Active Record" as it's developers say.
My questions are:
There any similar application like Habanero witch fully support Domain
Driven Design by determining aggregate roots, entities and value objects
Is it right decision to use such tools in big organizations
Does it worth training our team on such a tool
thank you
Framework support for Domain Driven Design is quite different from frameworks supporting data driven applications. Such framework should increase the productivity of developers that works with an ubiquitous language that evolves with the business and that is learned by a domain-expert.
They should not face concepts like aggregates, root, value objects because they are just modelling concepts, conceptual tools, but ways to ease the development process. Thus a framework exposing abstract classes or interfaces named AggregateRoot, Entity or ValueObject is fundamentally broken. It doesn't provides any real value to an application, just useless indirections.
However:
There are a few frameworks designed to support domain driven design, listed here. Moreover, I'm developing one by myself based on previous experiences that worked very well
It depends, obviosly. For example we used all of the Epic's modeling patterns with success.
We used some "home made" framewoks too, and some of them proved to really increase productivity. However, such frameworks (if useful) always have steep learning curves and it depends very much on how much reliable the software have to be and what are the developers skills.
It depends on the framework, on the complexity of the business (if you don't need a domain expert to understand it, you don't need DDD) and on the developers, too. I faced successful stories and huge failures with different frameworks in different contexts. I've also had a conference that faced the topic (you can see the slides here).
I am looking for a free software tool (or set of tools) to automate the document generation that requires the IEC 62304 and the FDA V&V standards (Software of Medical Equipments).
Basically, to maintain traceability between different documents, issue/bug trackers, SVN, source code, test cases, etc., report generation, document version control, project tracking, auditory functions, etc.
The Regulatory Documentation Manager (RDM) is a set of templates and python scripts which are designed to help automate IEC62304 compliance as much as possible. At its core, IEC62304 is all about using best practices to build high-quality software that has considered and mitigated as many risks as possible.
The stated design goals of RDM are:
Provide a generic template that covers common use-cases but is customizable.
Provide readable documents; e.g., other 62304 templates include many short deeply nested sub-sections. We use a maximum of two levels of nesting. We also provide flags (e.g., for different safety classes) that prune out irrelevant parts of the document, so that the documents only include what is necessary for the particular project.
Focused on software developers; the plan documents are intended to read and used frequently by the software developers on the team. Thus, wherever there was a tradeoff between making it easy to read for developers vs regulators/auditors, we optimized for developers. For example, we re-order IEC62304 sections to follow a more logical order for developers at the cost of being less parallel to IEC62304's structure.
Easy auditablility. In order to make it easier for regulators/auditors to read the document, we include auditor comments and links back to IEC62304. These links and notes are hidden by default, but there is a flag that enables turning them on. This way, we can use the "official" version without comments during our day-to-day work, but we can give the auditors two copies—both the "official" version and the "auditor" version that has all these extra notes.
Provide beautiful documents. A lot of times nobody readys requirements documents; we believe this is partly because the standard templates are large and ugly.
Make it as easy as possible to "upgrade" your documents when new versions of 62304 and related standards are developed.
The tool generates documents in markdown format, which are meant to be stored in source control, as well as in a PDF format. You can see examples of both the PDF and markdown versions here.
Please note that the tool is not complete, but it is under active development.
Not really related to regulatory compliance, but maybe Axiom can help. It can generate Word documents from your requirements.
There is a method called Model-Based Design by MathWorks which helps to integrate and automate most of the V&V processes required by the IEC 62304 for medical software development. In this way you can fulfil the steps all the way from requirements management to software integration and testing. The documentation artefacts required by the standard are automatically generated in the process.
I'm working on establishing automated testing practices and test suites in an organization. A peer is telling me that we "should use a framework". To me, a framework is any set of code and/or other tool that helps you create something.
My peer seems to be suggesting that there are industry standard automated testing frameworks.
I've seen the following patterns in designing Test systems before:
Data Driven
Keyword Driven
Model Driven
Query Driven
My counterpart includes "Modular" as one of these. Because of my background in Software Engineering, I hear the word "Modular" and think of modular programming (as opposed to object-oriented, aspect-oriented or procedural programming)... a way of organizing code, not a methodology or framework type in and of itself.
I've seen the wikipedia definition for "Modular Automation" and it looks the same as the programming paradigm.
What am I missing? What can I read to get on the same page as my counterpart? Is it me or him that doesn't understand something? I have over a decade of software engineering experience, my counterpart has been in QA for nearly that long. He's not able to site references. I've searched the google for 6 hours now trying to learn about this "Modular Framework" and can't find a technical example and nothing more than the standard programming paradigm (e.g. organize code into modules).
It turns out the major industry-standard designs for automated testing are:
Data Driven
Keyword Driven
Model Driven
Query Driven
Additionally, "hybrid" approaches are used. These are approaches in which more than one of the above designs are used.
In a number of places on the web (including wikipedia) "Modularity Driven" test case design is mistakenly referred to as if it were one of the automated test case design strategies listed above. The definition of this mistaken term ("Modularity Driven") appears to have more to do with the organizational aspects of coding than the way in which One drives an automated test. "Modularity Driven" automated testing is a misnomer (or mistaken term altogether). In other words, there is no such thing. The term "modular" describes the programming paradigm being used.
The modular aspect of a test is in its organization, storing code in modules as opposed to other programming paradigms like OOP, or Procedural, etc.
I have heard of Modular Automation also referred to as Component Based Test Case Design. HP is a big player in this space. The came up with a Product that is called Business Process Testing.
It consists of:
•Reusable Business Components
•Business Components converted into Business process test
Business components are reusable units that perform a specific task in a business process. (for example – Add to Cart)
A business process tests is a scenario comprising of business components (for example - Place an Order)
In HP's Quality Center the Business Components module enables you to create and manage reusable business components.
Then the Test Plan module enables you to drag and drop the components into business process tests, and debug the components.
If we need to use plugaable rule engine, what are all the open standards related to it.
How to migrate rule engine "without rewriting rules" for every platform?
JSR-94 is the only standard in wide use but, sadly, won't help you with rewriting rules as it is only a standard for calling the engine. If you want to avoid re-writing rules while either supporting multiple rule engines or moving from one to another then you need to look into a couple of other standards:
Production Rule Representation (PRR) is a standard under development at OMG. This defines the basic structure of rules and rulesets in rule engines so that an XML structure can be passed around containing rules. This is in beta and is being supported by most of the major rule vendors (though I don't think any have released support yet).
Rule Interchange Format (RIF) is a standard under development at W3C. This is being kept synchronized with PRR and is focused on the syntax of the rules - how to specify conditions etc. This is also widely supported but similarly support is not yet released.
The idea, and the reason the two teams work together, is to allow rules to be structured according to PRR (allowing them to be shared between modeling tools and rule engines) while exporting the rule engine-specific syntax to RIF so that specific rules can be moved from syntax to syntax.
Wikipedia says
Most Java-based rules engines provide
a technical call-level interface,
based on the JSR-94 application
programming interface (API) standard,
in order to allow for integration with
different applications, and many rule
engines allow for service-oriented
integrations through Web-based
standards such as WSDL and SOAP.
In general, it's still an early stage and I don't think there's still a dominating standard on the field. Also see The Rule Markup Initiative (RuleML). Besides JSR-94 and RuleML, Business Rule Management System mentions OMG Business Motivation Model (BMM), OMG SBVR, OMG Production Rule Representation (PRR), W3C RIF, and PMML.
You may also be interested in topics like BPEL, workflow engine, workflow application, and business process management.
At work I am responsible for writing specifications quite often and I am also the person who insisted on getting specifications in the first place. The problem is I am unsure how specifications should look and what they should contain. A lot of the time when my boss is writing the specifications (we are both inexperienced in it) they put in table names and things that I don't think belong there. So what is a good way to learn to write a good spec?
EDIT: Should a functional spec include things like assuming I am specifying a web application, the input types (a textbox, dropdown list, etc)?
The most important part of development documentation in my opinion, is having the correct person do it.
Requirements Docs - Users + Business Analyst
Functional Spec - Business Analyst + developer
Technical Spec (how the functionality will actually be implemented) - Sr. Developer /
Architect
Time estimates for scheduling purposes - The specific developer assigned to the task
Having anyone besides the Sr. Developer / Architect define table structures / interfaces etc. is an exercise in futility - as the more experienced developer will generally throw most of it out.
Wikipedia is actually a good start for the Functional Spec, which seems similar to your Spec - http://en.wikipedia.org/wiki/Functional_specification.
There's a great chapter in Steve McConnell's Code Complete that runs through specification documents and what they should contain.
When I was tasked to build an Architecture and Business Analysis team at a company that had never had either, I used McConnell's spec chapter to create the outline for the Technical Specification document. It evolved over time, but by starting out with this framework I made sure we didn't miss anything and it turned out to be surprisingly usable.
When writing specs, a rule of thumb I follow is to try to have technical documents always start from the general and move to the specific -- always restate the business problem(s) or goal(s) that the technical solution is being developed to solve, so the person reading the spec doesn't need to go to other documents to put it in any sort of context.
See Painless Functional Specs by Joel Spolsky.
Some of the things he says every spec should have:
A disclaimer
An author. One author
Scenarios
Nongoals
An Overview
Details, details, details
Open Issues
Side notes
The important thing is to get something written down rather than worry about the format.
Buy Books:
Requirements Engineering by Ian Sommerville & Pete Sawyer ISBN 0-471-97444-7
or
Software Requirements by Karl Wiegers ISBN 0-7356-0631-5