Requirements

Back to home

Requirements

Index

• Introduction
• Glossary
• Role: System
• Role: User
• Data: properties file
• Data: configuration file
• Data: resource file
• References

Introduction

The requirements are written according the SMART notation.

Glossary

The table below explains the glossary used in the requirements.

Term	Explanation
API	Stands for Application Programming Interface, a good API makes it easier to develop a computer program by providing all the building blocks, which are then put together by the programmer. See also wikipedia.
JVM	The Java Virtual Machine. See also wikipedia.
REST	In a RESTful Web service, requests made to a resource's URI will elicit a response that may be in XML, HTML, JSON or some other defined format. See also wikipedia.
SMART	Means: Specific, Measurable, Attainable, Relevant and Time-bound. See also wikipedia.

Role: System

See also use case

Functional requirements			Reference
The system should be able to <recognize> runtime <parameter>s when it starts			SYS-1
	<recognize> = provided as -D argument for the JVM		SYS-1.1
	<recognize> = provided as key value pair in a <properties file>. This value will override any value provided as -D (see also SYS-1.1)		SYS-1.2
		<properties file> = see definition here	PROP-1
	<parameter> = props (key), where it's value represents a path to a properties file. This key is optional.		SYS-1.3
	<parameter> = config (key), where it's value represents a path to a configuration file. If this value is not provided, the micro service will fall back to it's internal configuration for demo purposes.		SYS-1.4
	<parameter> = data (key), where it's value represents a path to a data folder, where all the resources reside for the responses. If this value is not provided, the micro service will fall back to it's internal resources for demo purposes.		SYS-1.5
	<parameter> = port (key), where it's value represents the port number the micro service will be listening to.		SYS-1.6
	<parameter> = log4j.configurationFile (key), where it's value represents a path to a log4j configuration file. This key is optional, and when omitted the micro service will fall back to an embedded configuration file.		SYS-1.7
The system should be able to <initialize> with a local <configuration file> when it starts			SYS-2
	<initialize> = <validate> against a <well defined format>		SYS-2.1
		<validate> = abort start when configuration file is not present	SYS-2.1.1
		<validate> = abort start when configuration file is not valid	SYS-2.1.2
		<well defined format> = schema specification, also known as XSD	SYS-2.1.3
		<well defined format> = bundled within micro service as static reference	SYS-2.1.4
	<initialize> = deploy REST operations when configuration file is valid		SYS-2.2
	<configuration file> = see definition here		CONFIG-1
The system should provide a <REST API> after it starts			SYS-3
	<REST API> = contains a command operation		SYS-3.1
	<REST API> = contains all configured operations, see SYS-2.2		SYS-3.2
The system should provide a <response> when it finds a <match>			SYS-4
	<response> = stream content from a <resource file> when it is not cached		SYS-4.1
		<resource file> = see definition here	RESOURCE-1
	<response> = added to cache when it is not cached		SYS-4.2
	<response> = stream content from cache when it is cached		SYS-4.3
	<response> = delay the streaming if configured, see CONFIG-2.3.2		SYS-4.4
	<response> = <generate an error> if configured, see CONFIG-2.3.3		SYS-4.5
		<generate an error> = when error rate is smaller or equal than the generated random number (1-100). See also CONFIG-2.3.3.1	SYS-4.5.1
		<generate an error> = respecting error code, see CONFIG-2.3.3.2	SYS-4.5.2
	<response> = generate custom content type when specified. See also CONFIG-2.3.4		SYS-4.6
	<match> = exactly the same as the configured URI when it does not contain a wild card, see CONFIG-2.2.1		SYS-4.7
	<match> = matches the regular expression when it does contain a wild card, see CONFIG-2.2.2		SYS-4.8
	<match> = URI is not equals to /mock/cmd as that is reserved for handling commands		SYS-4.9

Role: User

See also use case

Functional requirements			Reference
The system should execute a <command> when it finds a <match>			USER-1
	<match> = URI is equals to /mock/cmd as that is reserved for handling commands. See also SYS-3.1		USER-1.1
	<match> = URI contains request query parameter (i.e. ?key=value)		USER-1.2
	<command> = config, which will re-configure the running instance with the provided value. The value represents a path to the configuration file. See CONFIG-1		USER-1.3
	<command> = log, which will re-configure the verbosity of the logging framework used. The value can be: ERROR, WARN, INFO, DEBUG or OFF		USER-1.4
	<command> = stats, which will report the statistics gathered by the used web container. The stats will be reported in HTML format when the value is equal to html		USER-1.5
	<command> = reset, which will reset the statistics		USER-1.6
	<command> = stop, which will terminate the mock service		USER-1.7

Data: properties file

Reference	Requirement
SYS-1.2	<recognize> = provided as key value pair in a <properties file>. This value will override any value provided as -D

Functional requirements				Reference
<properties file> = configurable file name and location				PROP-1
<properties file> = Text file with <key>-value pairs				PROP-2
	<key> = port, see also SYS-1.6			PROP-2.1
	<key> = config, see also SYS-1.4			PROP-2.2
	<key> = data, see also SYS-1.5			PROP-2.3
	<key> = log4j.configurationFile, see also SYS-1.7			PROP-2.4

Data: configuration file

Reference	Requirement
SYS-1	The system should be able to initialize with a local <configuration file> when it starts

Functional requirements				Reference
<configuration file> = configurable file name and location				CONFIG-1
<configuration file> = XML file with <single> and <grouped> <configuration definition>s				CONFIG-2
	<configuration definition> = contains a HTTP <request type>			CONFIG-2.1
		<request type> = GET, POST, PUT, DELETE, ...		CONFIG-2.1.1
	<configuration definition> = contains an <URI> to bind the REST API on			CONFIG-2.2
		<URI> = a path starting with a forward slash, i.e. '/', such as /test/1		CONFIG-2.2.1
		<URI> = may contain wildcards. i.e. '*', such as /test/*		CONFIG-2.2.2
	<single> = contains a <resource definition> that represents the response associated with the URI			CONFIG-2.3
		<resource definition> = relative path to a resource file containing the verbatim response		CONFIG-2.3.1
		<resource definition> = may contain a <delay> configuration		CONFIG-2.3.2
			<delay> = in milli seconds	CONFIG-2.3.2.1
		<resource definition> = may contain a <error> configuration		CONFIG-2.3.3
			<error> = contains error rate in percentage	CONFIG-2.3.3.1
			<error> = contains error code (HTTP status such as 500, 404, ...)	CONFIG-2.3.3.2
		<resource definition> = may contain a <content-type> configuration		CONFIG-2.3.4
			<content-type> = HTTP content-type aka mime-type (such as application/json)	CONFIG-2.3.4.1
	<grouped> = may contain <namespaces>			CONFIG-2.4
		<namespaces> = a <namespace> is typically used in XML files		CONFIG-2.4.1
			<namespace> = contains a prefix	CONFIG-2.4.1.1
			<namespace> = contains a URL	CONFIG-2.4.1.2
	<grouped> = contains a list of entries with a <matcher> and a resource definition per entry			CONFIG-2.5
		<matcher> = xpath expression when the body is in XML format		CONFIG-2.5.1
		<matcher> = jsonpath expression when the body is in Json format		CONFIG-2.5.2

Data: resource file

Reference	Requirement
SYS-4.1	<response> = stream content from a <resource file> when it is not cached

Functional requirements				Reference
<resource file> = configurable file name and location				RESOURCE-1
<resource file> = contains text, which can be of any type. See also SYS-4.6				RESOURCE-2

References

The following reference are noteworthy, ordered by alphabet:

URL	Description